Use Sentry's OpenAPI schema as source of truth for API interactions

[betegon]

Problem

The CLI currently hardcodes API endpoint paths, request parameters, and response types. This creates a maintenance burden and risk:

• If Sentry's API changes (endpoints renamed, fields deprecated, types changed), the CLI could break at runtime with confusing errors
• No automated way to detect when the CLI is out of sync with the actual API
• Duplicated effort maintaining types that already exist in the official schema

Sentry publishes an official OpenAPI v3 schema at getsentry/sentry-api-schema (openapi-derefed.json). This is the source of truth for the public API.

Possible Solutions

1. Generate TypeScript types from the schema - Use tooling like openapi-typescript to generate request/response types at build time. The CLI would import these instead of maintaining manual type definitions.

2. CI validation - Add a GitHub Action that compares the CLI's expected endpoints/types against the published schema. Fail the build if there's a mismatch or if deprecated endpoints are used.

3. Runtime schema validation - Embed or fetch the schema and validate request parameters before sending. Could provide better error messages ("field X was renamed to Y").

4. Schema-driven api command - Enhance sentry api with awareness of available endpoints, providing auto-completion, parameter hints, and validation based on the schema.

5. Code generation for commands - Generate boilerplate for new commands (like sentry org list) directly from OpenAPI operation definitions.

References

• OpenAPI schema repo: https://github.com/getsentry/sentry-api-schema
• Schema file: openapi-derefed.json (dereferenced, ~3MB)
• OpenAPI version: 3.0.3