Catalog
getsentry/document-api-endpoint

getsentry

document-api-endpoint

Document and type a Sentry API endpoint. Write or fix @extend_schema decorators, specify response TypedDicts, type request parameters, correct type drift between the declared schema and the runtime response, and validate the generated spec. Use when asked to "document an endpoint", "add OpenAPI docs", "add/fix @extend_schema", "type an endpoint response", "fix the response type", "fix type drift", "reuse a response type", "split an overloaded endpoint", "specify the response schema", "add a TypedDict response", "migrate a legacy api-docs path", "fix a parameter type", or "make an endpoint public" / "promote an endpoint" (promotion is one section here).

global
New~1.1k
v1.0Saved Jul 11, 2026

Document & Type a Sentry API Endpoint

Add or fix OpenAPI docs for a Sentry endpoint with drf-spectacular. Full reference is at https://develop.sentry.dev/backend/api/public/, the most useful section to you will be https://develop.sentry.dev/backend/api/public/#5-method-decorator. This skill captures the non-obvious lessons on top of it. Most of the work is making the declared schema match what the endpoint actually returns. Before documenting, identify which endpoint class serves the route and what it does; the MCP tool that calls it is usually the fastest way to confirm its behavior. Promoting a PRIVATE/EXPERIMENTAL endpoint to PUBLIC is one application (see below).

Workflow

  1. Class-level @extend_schema(tags=[...]) — use the closest existing OPENAPI_TAGS entry.
  2. Method-level @extend_schema(operation_id=..., parameters=[...], responses={...}, examples=...).
  3. Reuse src/sentry/apidocs/parameters.py and examples/*.py; ensure owner = ApiOwner.<TEAM> is set.
  4. If a legacy api-docs/paths/**/*.json covers the path, remove it (see lesson 4).
  5. Validate, then verify against the live endpoint (lesson 1).

Lessons

1. Carefully compare what the code does vs declared types

Ideally, hit the live endpoint with a real token and diff the keys and types against your TypedDict. Serializers are sometimes inaccurate. Look out for counts coming back as floats instead of integers, IDs declared int emitted as strings, nested types declaring the wrong number of fields. Correct the declared type to match runtime.

curl -s -H "Authorization: Bearer $TOKEN" "https://us.sentry.io/api/0/<endpoint>" | jq 'keys'

2. Reuse the canonical response type

Match the codebase's XxxResponseOptional(TypedDict, total=False) mixin (main class declares required fields). Nullable-vs-absent: T | None = key always present, value may be null; NotRequired[T] = key only set under a condition (e.g. an expand query param). Reuse the existing canonical type instead of re-declaring a second or third copy in a *_types.py. If there's no clean canonical type to reuse (e.g. a payload proxied from another service like vroom/profiling), type it dict[str, Any] rather than inventing a new mirror, and confirm the shape from the owning service's repo, not just the serializer.

3. Infer the type. Avoid cast and # type: ignore

When a serializer returns a base type plus extra fields, refactor the producing code so the response type is inferred rather than forced.

4. Legacy doc migration is all-or-nothing per path

Delete the api-docs/paths/**/*.json file AND its $ref in api-docs/openapi.json. drf-spectacular's APPEND_PATHS does not merge HTTP methods, so once any method on a path uses @extend_schema, all legacy methods on that path vanish — migrate every method on the path in one commit.

Promoting to PUBLIC

Do the workflow above, then on the concrete endpoint only (leave siblings PRIVATE):

  • Bump publish_status[<METHOD>]PUBLIC and set owner = ApiOwner.<TEAM>.
  • Remove the method from API_OWNERSHIP_ALLOWLIST_DONT_MODIFY in the same change as the flip.
  • If the endpoint is redundant or being renamed, delete or deprecate the old version in its own change first, then stack the publish on top.
  • Note in the PR if scopes widen (event:readevent:{admin,read,write}) — that's drf-spectacular regenerating from permission_classes, documentation-only.

The change reaches the @sentry/api SDK / MCP only after sentry-api-schema regenerates downstream.

Validate

make build-api-docs
pnpm run validate-api-examples
.venv/bin/pytest -q --reuse-db tests/apidocs/endpoints/<area>/test_<name>.py
.venv/bin/prek run -q --files <changed paths>
Files1
1 files · 10.5 KB

Select a file to preview

Overall Score

82/100

Grade

B

Good

Safety

82

Quality

85

Clarity

82

Completeness

76

Summary

This skill guides agents to document and type Sentry API endpoints using drf-spectacular decorators, OpenAPI schema definitions, and TypedDict response types. It covers the full workflow from adding @extend_schema decorators, managing response types and type drift, validating the generated spec, and promoting endpoints from PRIVATE to PUBLIC status. The skill emphasizes matching declared schemas to runtime behavior and reusing canonical response types across the codebase.

Detected Capabilities

file readfile writeshell execution (curl, make, pytest, pnpm)code analysis and type inferenceREST API calls

Trigger Keywords

Phrases that MCP clients use to match this skill to user intent.

document api endpointadd openapi docsfix extend_schema decoratortype endpoint responsefix type driftpromote endpoint to publicmigrate api-docs pathvalidate api spec

Risk Signals

INFO

Curl request to live Sentry API using bearer token ("Authorization: Bearer $TOKEN")

Lesson 1, code block
INFO

References external Sentry documentation domains (develop.sentry.dev, us.sentry.io)

Frontmatter description and Lesson 1
WARNING

Instructs deletion of legacy api-docs/paths JSON files

Workflow step 4 and Lesson 4

Referenced Domains

External domains referenced in skill content, detected by static analysis.

develop.sentry.devus.sentry.iowww.apache.org

Use Cases

  • Add OpenAPI documentation to an undocumented API endpoint using @extend_schema
  • Fix type drift between declared response schema and runtime endpoint behavior
  • Reuse canonical TypedDict response types across multiple API endpoints
  • Promote a PRIVATE or EXPERIMENTAL endpoint to PUBLIC with proper ownership
  • Migrate legacy api-docs/paths JSON files to drf-spectacular @extend_schema decorators
  • Type request parameters and specify response schemas for an existing endpoint
  • Validate generated OpenAPI spec and test endpoint documentation against live service

Quality Notes

  • Strong foundational structure with clear workflow steps and numbered lessons that build on each other
  • Practical guidance on subtle issues (e.g., nullable vs. absent fields, type drift detection) backed by reasoning
  • Lesson 2 explicitly enforces type reuse and discourages duplication or overly broad types (dict[str, Any])
  • Lesson 3 promotes type inference over casts, guiding agents toward cleaner code
  • Validation section provides concrete commands (make build-api-docs, pytest, prek) with clear scope
  • Promotion workflow is well-documented with specific steps and caveats (scope widening, deprecation ordering)
  • Legacy migration guidance is all-or-nothing, reducing risk of inconsistent specs
  • Some implicit assumptions: agents are expected to understand drf-spectacular, TypedDict syntax, and Sentry's endpoint structure — minimal scaffolding for these prerequisites
Model: claude-haiku-4-5-20251001Analyzed: Jul 11, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Add getsentry/document-api-endpoint to your library

Command Palette

Search for a command to run...