Sentry CLI calls endpoints that aren't in the public API schema: publish or keep private?

@BYK

For the API owners (@getsentry/owners-api), plus each endpoint's owning team listed below.

The Sentry CLI is moving every Sentry API call onto the generated @sentry/api operations (getsentry/toolkit#2073). An Oxlint rule will then ban the CLI's hand-written apiRequest* helpers, with no allowlist. @sentry/api is generated from this repo's OpenAPI output (make build-api-docs), so an endpoint that isn't in the public schema has no generated operation, and the CLI can't move off the helper for it.

The endpoints below are what's left. Most look private on purpose. For each one, can the owning team decide whether it should be:

published in the public API docs (set publish_status to PUBLIC and add extend_schema docs), or
kept private, in which case the CLI keeps a sanctioned exception for that call.

Method and path are relative to /api/0/. Publish status and owner are from publish_status / owner on master.

Method & path	Endpoint (status, owner)	CLI commands	Looks private on purpose?
GET `/`	`IndexEndpoint` (PRIVATE, UNOWNED)	Every command, via 403 scope recovery (`getCurrentAuthScopes`)	Yes: API root, token introspection
GET `/auth/`	`AuthIndexEndpoint` (PRIVATE, FOUNDATIONS)	`auth login`, `auth whoami`, `info`	Yes: session/auth internals
GET `/users/me/regions/`	`UserRegionsEndpoint` (PRIVATE, HYBRID_CLOUD)	`auth login`, plus region fan-out for org and project resolution	Yes: hybrid-cloud routing
GET `/projects/?query=dsn:{key}`	`ProjectIndexEndpoint` (PRIVATE, UNOWNED)	DSN-based project auto-detection used by most project-scoped commands	Probably. The `dsn:` search key is only handled here, not on the public `listOrganizationProjects`
GET, PUT `/issues/{issue_id}/` (unscoped)	`GroupDetailsEndpoint` (PUBLIC, ISSUES)	`issue view/resolve/unresolve/archive` and feedback commands, when only a numeric issue ID is known	No. Only the org-scoped path is documented. Either document the unscoped alias, or the CLI resolves the org first
GET `/organizations/{org}/shared/issues/{share_id}/`	`SharedGroupDetailsEndpoint` (PRIVATE, ISSUES)	`issue view <share URL>` (raw `customFetch`, unauthenticated)	Yes: public share links
GET `/organizations/{org}/releases/{version}/previous-with-commits/`	`OrganizationReleasePreviousCommitsEndpoint` (PRIVATE, ISSUES)	`release set-commits` (auto mode)	Yes: internal helper
GET `/organizations/{org}/dashboards/{id}/revisions/`	`OrganizationDashboardRevisionsEndpoint` (PRIVATE, DASHBOARDS)	`dashboard revisions`	Unclear: newer feature, may just not be published yet
POST `/organizations/{org}/dashboards/{id}/revisions/{revision_id}/restore/`	`OrganizationDashboardRevisionRestoreEndpoint` (PRIVATE, DASHBOARDS)	`dashboard restore`	Unclear, same as above
GET `/organizations/{org}/trace-logs/`	`OrganizationTraceLogsEndpoint` (PRIVATE, DATA_BROWSING)	`log list`, `trace logs`	Unclear: it already has full `extend_schema` docs but is PRIVATE
GET `/projects/{org}/{project}/trace-items/{item_id}/`	`ProjectTraceItemDetailsEndpoint` (EXPERIMENTAL, DATA_BROWSING)	`log view`	Unclear: EXPERIMENTAL
GET, POST `/organizations/{org}/org-auth-tokens/`, DELETE `…/{token_id}/`	`OrganizationAuthTokensEndpoint`, `OrganizationAuthTokenDetailsEndpoint` (PRIVATE, FOUNDATIONS)	`token list`, `token create`, `token delete`	Unclear: tokens are sensitive, but the CLI exposes them as a user feature
POST `/projects/{org}/{project}/files/preprodartifacts/assemble/`	`ProjectPreprodArtifactAssembleEndpoint` (EXPERIMENTAL, EMERGE_TOOLS)	`build upload`	Unclear: EXPERIMENTAL
GET `/projects/{org}/{project}/preprodartifacts/snapshots/upload-options/`	`ProjectPreprodUploadOptionsEndpoint` (PRIVATE, EMERGE_TOOLS)	`snapshots upload`	Likely: upload transport config
GET, POST `/organizations/{org}/preprodartifacts/snapshots/{snapshot_id}/archive/`, plus the archive download	`OrganizationPreprodSnapshotArchiveEndpoint` (PRIVATE, EMERGE_TOOLS)	`snapshots download` (the download is a raw `customFetch`)	Likely: archive transport
GET `/customers/{org}/`, PUT `/customers/{org}/product-trial/`	getsentry billing endpoints (not in this repo)	`trial list`, `trial start`, Seer trial prompts	Yes: SaaS billing

Two related items:

POST /projects/{org}/{project}/preprodartifacts/snapshots/ (ProjectPreprodSnapshotEndpoint, PUBLIC, EMERGE_TOOLS) is in the schema, but with request=None, so the generated body type is never. The body is validated against SNAPSHOT_POST_REQUEST_SCHEMA and can be sent zstd-encoded (Content-Encoding: zstd). Should the body be documented (snapshots upload would need it), or is this endpoint meant to be called only by Sentry's own tooling? Either way, the CLI may still need a transport exception for the zstd body.
Replay list field=info_ids / field=warning_ids were hidden from the public enum on purpose in fix(replays): Withhold internal field choices from the public replay schema #128639. The CLI will stop requesting them instead of asking to publish them.

These doc-mismatch PRs cover the endpoints that are already public but whose docs didn't match the code: #130348 (issue update bodies), #130349 (timeseries yAxis/interval, trace timestamp) and #130350 (AI conversations sort).

Refs getsentry/toolkit#2073

via @BYK.

--

View Session [Sentry]