[GH-ISSUE #762] feat: add raw API passthrough command for arbitrary ASC API requests #207

New issue

Closed

opened 2026-02-26 21:34:00 +03:00 by kerem · 1 comment

kerem commented

2026-02-26 21:34:00 +03:00

Owner

Originally created by @mithileshchellappan on GitHub (Feb 24, 2026).
Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/762

Summary

Add a generic API passthrough command (asc api) that allows sending arbitrary authenticated requests to the App Store Connect API, similar to gh api in the GitHub CLI.

Problem

The asc CLI has excellent coverage of common ASC workflows, but agents occasionally need to hit endpoints that do not yet have dedicated subcommands, or need to use specific query parameters/relationships not yet exposed as flags.

During a recent TestFlight distribution workflow, I needed to add a build to a beta group. The asc testflight beta-groups subcommand had no add-builds action, and asc builds add-groups was the correct path — but discovering this required trial and error across multiple subcommand trees. A raw API escape hatch would have resolved this immediately:

# Hypothetical — would have worked immediately
asc api POST /v1/betaGroups/GROUP_ID/relationships/builds \
  --body '{"data":[{"type":"builds","id":"BUILD_ID"}]}'

Every major CLI tool provides this escape hatch:

GitHub CLI: gh api
AWS CLI: aws <service> --cli-input-json
Google Cloud CLI: gcloud alpha api-gateway ... / raw REST
Stripe CLI: stripe get /v1/...

Proposal

# GET request
asc api GET /v1/apps --query "filter[bundleId]=com.example.app"

# POST with JSON body
asc api POST /v1/betaGroups/GROUP_ID/relationships/builds \
  --body '{"data":[{"type":"builds","id":"BUILD_ID"}]}'

# PATCH
asc api PATCH /v1/betaBuildLocalizations/LOC_ID \
  --body '{"data":{"type":"betaBuildLocalizations","id":"LOC_ID","attributes":{"whatsNew":"notes"}}}'

# DELETE
asc api DELETE /v1/builds/BUILD_ID/relationships/betaGroups \
  --body '{"data":[{"type":"betaGroups","id":"GROUP_ID"}]}'

# Pipe body from stdin
echo '{"data":{...}}' | asc api POST /v1/... --body -

# With pagination
asc api GET /v1/builds --query "filter[app]=APP_ID" --paginate

Flags

Flag	Description
`--body`	JSON request body (string or `-` for stdin)
`--query`	Query string parameters (repeatable)
`--header`	Additional headers (repeatable)
`--paginate`	Follow `links.next` and collect all pages
`--output`	Output format: `json` (default), `table`
`--pretty`	Pretty-print JSON output
`--jq`	Apply jq expression to output (like `gh api --jq`)

Authentication

Reuse the existing asc auth credential resolution — the command should automatically attach the JWT bearer token from the configured API key.

Scope

internal/cli/api/api.go: new top-level api command
Reuse existing HTTP client and auth token generation from internal/asc
Support all HTTP methods (GET, POST, PATCH, DELETE)
Optional: --jq flag for inline JSON filtering

Acceptance Criteria

asc api GET /v1/apps returns authenticated JSON response
asc api POST /v1/... --body '{...}' sends authenticated POST with body
Authentication uses existing asc auth configuration (API key, issuer, key ID)
--paginate follows links.next and merges data arrays
--pretty formats JSON output
Exit code reflects HTTP status (0 for 2xx, non-zero otherwise)
Tests pass with ASC_BYPASS_KEYCHAIN=1

Use Case

This is the single most impactful feature for agent workflows. Agents frequently encounter edge cases where they need a specific API call that either:

Has no dedicated subcommand yet
Requires specific filter/relationship parameters not exposed as flags
Needs a newer API endpoint added after the CLI release

Rather than blocking on a CLI release for each new endpoint, asc api lets agents self-serve immediately while dedicated commands are built over time. It also serves as an excellent debugging and exploration tool for developers building on the ASC API.

Originally created by @mithileshchellappan on GitHub (Feb 24, 2026). Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/762 ## Summary Add a generic API passthrough command (`asc api`) that allows sending arbitrary authenticated requests to the App Store Connect API, similar to `gh api` in the GitHub CLI. ## Problem The `asc` CLI has excellent coverage of common ASC workflows, but agents occasionally need to hit endpoints that do not yet have dedicated subcommands, or need to use specific query parameters/relationships not yet exposed as flags. During a recent TestFlight distribution workflow, I needed to add a build to a beta group. The `asc testflight beta-groups` subcommand had no `add-builds` action, and `asc builds add-groups` was the correct path — but discovering this required trial and error across multiple subcommand trees. A raw API escape hatch would have resolved this immediately: ```bash # Hypothetical — would have worked immediately asc api POST /v1/betaGroups/GROUP_ID/relationships/builds \ --body '{"data":[{"type":"builds","id":"BUILD_ID"}]}' ``` Every major CLI tool provides this escape hatch: - **GitHub CLI**: `gh api` - **AWS CLI**: `aws <service> --cli-input-json` - **Google Cloud CLI**: `gcloud alpha api-gateway ...` / raw REST - **Stripe CLI**: `stripe get /v1/...` ## Proposal ```bash # GET request asc api GET /v1/apps --query "filter[bundleId]=com.example.app" # POST with JSON body asc api POST /v1/betaGroups/GROUP_ID/relationships/builds \ --body '{"data":[{"type":"builds","id":"BUILD_ID"}]}' # PATCH asc api PATCH /v1/betaBuildLocalizations/LOC_ID \ --body '{"data":{"type":"betaBuildLocalizations","id":"LOC_ID","attributes":{"whatsNew":"notes"}}}' # DELETE asc api DELETE /v1/builds/BUILD_ID/relationships/betaGroups \ --body '{"data":[{"type":"betaGroups","id":"GROUP_ID"}]}' # Pipe body from stdin echo '{"data":{...}}' | asc api POST /v1/... --body - # With pagination asc api GET /v1/builds --query "filter[app]=APP_ID" --paginate ``` ### Flags | Flag | Description | |------|-------------| | `--body` | JSON request body (string or `-` for stdin) | | `--query` | Query string parameters (repeatable) | | `--header` | Additional headers (repeatable) | | `--paginate` | Follow `links.next` and collect all pages | | `--output` | Output format: `json` (default), `table` | | `--pretty` | Pretty-print JSON output | | `--jq` | Apply jq expression to output (like `gh api --jq`) | ### Authentication Reuse the existing `asc auth` credential resolution — the command should automatically attach the JWT bearer token from the configured API key. ## Scope - `internal/cli/api/api.go`: new top-level `api` command - Reuse existing HTTP client and auth token generation from `internal/asc` - Support all HTTP methods (GET, POST, PATCH, DELETE) - Optional: `--jq` flag for inline JSON filtering ## Acceptance Criteria - `asc api GET /v1/apps` returns authenticated JSON response - `asc api POST /v1/... --body '{...}'` sends authenticated POST with body - Authentication uses existing `asc auth` configuration (API key, issuer, key ID) - `--paginate` follows `links.next` and merges `data` arrays - `--pretty` formats JSON output - Exit code reflects HTTP status (0 for 2xx, non-zero otherwise) - Tests pass with `ASC_BYPASS_KEYCHAIN=1` ## Use Case This is the single most impactful feature for agent workflows. Agents frequently encounter edge cases where they need a specific API call that either: 1. Has no dedicated subcommand yet 2. Requires specific filter/relationship parameters not exposed as flags 3. Needs a newer API endpoint added after the CLI release Rather than blocking on a CLI release for each new endpoint, `asc api` lets agents self-serve immediately while dedicated commands are built over time. It also serves as an excellent debugging and exploration tool for developers building on the ASC API.

kerem closed this issue

2026-02-26 21:34:00 +03:00

kerem commented

2026-02-26 21:34:01 +03:00

Author

Owner

@rudrankriyam commented on GitHub (Feb 24, 2026):

As discussed, there are no new ones, and the tradeoff for the model to web search the endpoint is not worth it vs trying to figure it out itself

@rudrankriyam commented on GitHub (Feb 24, 2026): As discussed, there are no new ones, and the tradeoff for the model to web search the endpoint is not worth it vs trying to figure it out itself