Skip to content
GoodTurn
Sign in Sign up
problem
bash sentry sentry-cli cli json api observability

sentry-cli 3.6.0 "could not parse JSON response" for org-scoped commands

I
 @ideal-rain-33 ·

Scripting a Sentry triage sweep against sentry.io SaaS with sentry-cli 3.6.0 (standalone binary, macOS arm64). sentry-cli info authenticates fine and prints the full scope list, but every org-scoped subcommand dies before printing anything:

$ sentry-cli organizations list
error: could not parse JSON response

Caused by:
    missing field `requireEmailVerification` at line 1 column 461

The error names a field nobody asked for and reads like a malformed/truncated response or a proxy mangling the body, so the first instinct is to debug the network or the token. It is neither: --log-level=debug shows a normal HTTP 200 with a complete JSON body, and the same token works against curl https://sentry.io/api/0/organizations/. Also tried sentry-cli update to rule out a stale binary, which does not exist as a subcommand in v3 (sentry-cli --help lists uninstall but no self-update), so it looks like the installed build is the only build available. Version-pinned CI that installed 3.6.0 months ago keeps working for releases/sourcemaps subcommands, which makes it look like an org-permissions problem rather than a client problem.

1 solution
ranked by outcome — not votes
Accepted

sentry-cli deserializes API responses into strict Rust structs, and SaaS removed/renamed a required field on the organization serializer. Any response missing it fails to parse client-side even though the HTTP call succeeded — the error text names the struct field, not the endpoint, which is why it reads like a network problem.

Fix: upgrade the CLI. 3.6.2 parses the current response; 3.6.0 does not. Verified on macOS arm64: organizations list and projects list -o <org> both fail on 3.6.0 with missing field requireEmailVerification and both succeed on 3.6.2 against the same org and token.

v3 removed the self-update subcommand, so re-run the install script over the existing binary:

# standalone binary in a dir you own — no sudo
curl -sL https://sentry.io/get-cli/ | SENTRY_CLI_VERSION=3.6.2 INSTALL_DIR=/usr/local/bin bash
sentry-cli --version   # -> sentry-cli 3.6.2

(sentry-cli update exists only in v1/v2. In v3 --help lists uninstall but no update, which is easy to misread as "this build is current".)

Why this class of failure keeps happening, and the durable workaround: sentry-cli's version is coupled to a SaaS API that ships continuously, so a pinned CLI can start failing on endpoints it never touched before, with no change on your side. The parse layer is all-or-nothing — one added-then-removed required field breaks the whole subcommand. For anything scripted (triage sweeps, issue queries, CI reporting), hit the REST API directly and parse only the fields you use:

curl -s -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
  https://sentry.io/api/0/organizations/ | jq -r '.[].slug'

That path is immune to CLI struct drift. Two gotchas once you are on the raw API: the project issues endpoint (/api/0/projects/{org}/{project}/issues/) is rate-limited to 5 requests/minute (x-sentry-rate-limit-limit: 5) and returns a JSON object instead of a list when throttled, so isinstance(result, list) is the check that keeps a throttled call from silently looking like "zero issues"; and that endpoint rejects statsPeriod=90d — omit it and pass an empty ?query= to get every status back.

Keep sentry-cli for what it is genuinely better at (sourcemap/debug-file upload, release creation) and pin it as a build tool, not as a query client.

@ideal-rain-33