What this prompt does
This prompt generates complete, copy-ready endpoint documentation in a Stripe-style reference quality. It casts the assistant as a senior API technical writer and takes context variables describing the endpoint — [method], [path], [service] — and the [auth_scheme]. The deliverables are a one-sentence purpose plus the authentication requirement, a request parameters table (name, type, required, description), a request example as both a curl command and a JSON body, the response schema with field descriptions, response examples for 200 plus the two most common error codes, and rate-limit and idempotency behaviour. The output is Markdown crisp enough to drop into an OpenAPI spec or reference page.
The structure works because inconsistent endpoint docs are what turn an integration into a week of back-and-forth. By forcing a fixed shape — purpose, params table, dual request examples, response schema, error examples, and rate-limit/idempotency notes — the prompt matches a known-good reference style so consumers rarely have to ask how auth or errors actually work. Pasting your real validation rules is what keeps the required column and error examples accurate rather than invented.
When to use it
- Documenting REST endpoints you're shipping for client or partner integrations
- When inconsistent endpoint docs are causing repeated integration questions
- When you want Stripe-quality reference pages without writing them by hand
- When docs need both a curl example and a JSON body for each request
- When error responses and idempotency behaviour keep getting asked about
- When you're populating or backfilling an OpenAPI spec
Example output
You get crisp Markdown for one endpoint: a one-sentence purpose and auth requirement, a parameters table with name, type, required, and description columns, a request shown as both a curl command and a JSON body, the response schema with each field described, response examples for a 200 and the two most common error codes, and a note on rate-limit and idempotency behaviour. It's formatted to drop into an OpenAPI spec or a Stripe-style reference page with minimal editing. The error examples are easy to overlook but pull the most weight, because integrators spend more time handling the failure cases than the happy path, and docs that show real error bodies save them from guessing at your error shape.
Pro tips
- Paste your real validation rules so the required column and error examples are accurate rather than invented
- Set
[auth_scheme]precisely ("Bearer token (OAuth 2.0)") so the authentication requirement matches your actual implementation - Give the true
[method]and[path]so the curl example and route are correct out of the box - Verify the rate-limit and idempotency notes against your real behaviour, since the model will guess if you don't specify
- Run the generated curl command against a test environment to confirm the example actually works
- Keep one endpoint per run; documenting several at once dilutes the per-endpoint detail
