[sentry-junior]

Stacked on #1807. It also carries #2213's commit, which is already on main but not on #1807's branch; it drops out of the diff once #1807 picks up main.

This follows up @BYK's suggestion on #2213: normalizeEndpoint now templates paths with the @sentry/api OpenAPI path templates and matchApiPathTemplate, instead of a regex list. generate-api-schema.ts writes the 173 unique paths (~14 KB) to src/generated/api-path-templates.json, next to idempotent-operations.json, so the CLI never loads the full catalog. The template that matches the most of the path wins. Any segment past that match that no template spells out becomes {id}, so a path outside the catalog doesn't leak. This covers cli_error.api_endpoint, api_error.endpoint, and the http.client span description and URL attributes. The install-prefix and /api/0 handling from #2213 are unchanged.

Placeholder names change. Existing cli_error.api_endpoint values change too: {org} becomes {organization_id_or_slug}, {project} becomes {project_id_or_slug}, and {id} becomes the catalog's name where there is one, such as {issue_id} or {event_id}. Nothing in this repo keys on the old form except error-reporting.test.ts, which this PR updates. In Sentry, none of the sentry/cli fingerprint rules, issue alerts, or metric alerts reference cli_error.api_endpoint, and neither does any widget on the 12 CLI dashboards.

Endpoints missing from the public catalog, such as /auth/, /envelope/, and events-stats, now report {id} in place of their name. Full URLs outside /api/0/, such as OAuth or GitHub, are left as they are.

Before

cli_error.api_endpoint: /api/0/projects/{org}/{project}/events/{id}/
api_error.endpoint:     organizations/{org}/releases/
span.description:       GET https://sentry.example.com/sentry/api/0/organizations/{org}/issues/
cli_error.api_endpoint: organizations/{org}/not-an-endpoint/my-thing/

After

cli_error.api_endpoint: /api/0/projects/{organization_id_or_slug}/{project_id_or_slug}/events/{event_id}/
api_error.endpoint:     organizations/{organization_id_or_slug}/releases/
span.description:       GET https://sentry.example.com/sentry/api/0/organizations/{organization_id_or_slug}/issues/
cli_error.api_endpoint: organizations/{organization_id_or_slug}/{id}/{id}/

via @betegon.

--

View Session [Sentry]

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Nov 13, 2026 7:46am UTC

[BYK]

Should this also come from the @sentry/api package? We can make it happen

[sentry-junior]

Yes, I think it should. @sentry/api doesn't export the API prefix today, in 0.428.0 on this branch or 1.59.0 on main. Toolkit defines "/api/0" privately in three places: toolkit-core/src/api-client/core.ts, cli/src/commands/api.ts, and now error-reporting.ts. An export from @sentry/api, for example next to buildSentryApiUrl, would let all three share it.

[BYK]

Well then, make it happen. Ideally this would come all the way from the source in getsentry/sentry so we don't drift.

[sentry-junior]

I looked at what it would take to source this from the spec:

• getsentry/sentry: the OpenAPI spec's servers entry is just https://{region}.sentry.io. /api/0 is spelled out at the start of every path in the spec, so the prefix isn't a separate field there today.
• getsentry/sentry-api-schema (publishes @sentry/api): the prefix is private there too. It's a const API_PREFIX in lib/api-client/core.ts, plus hard-coded /api/0/ in api-path.ts and api-path-scope.ts.

To avoid drift, sentry-api-schema could derive the prefix from the spec's paths at build time and export it. toolkit's three copies would then import it. Moving /api/0 into servers in getsentry/sentry would also work, but it changes the spec for every client.

This is a change in other repos, so I'm checking the scope with @betegon before I start. I'll leave this thread open until then.