What this prompt does
This prompt asks the AI to generate a complete OpenAPI 3.1 specification for [api_name], covering [endpoint_count] endpoints across [resource_groups]. For each endpoint it defines paths with parameters, request bodies with examples, success and error response schemas, security requirements, and rate-limit docs. It adds reusable components, discriminated unions for polymorphic types, and webhook definitions for [webhook_events] — then generates typed client SDK stubs for [sdk_languages] with retry logic, error handling, interceptors, and usage examples, plus a Postman collection.
The structure works because spec-first development pays off downstream: a good OpenAPI document becomes the single source for SDKs, docs, and mock servers. Setting [endpoint_count] and [resource_groups] scopes how much surface the model covers and keeps it organized. [webhook_events] defines the async surface that's easy to forget, and [sdk_languages] determines which typed clients get generated. Because everything derives from one spec, the SDKs and Postman collection stay consistent with the contract.
When to use it
- You're starting an API and want a clean OpenAPI 3.1 contract before coding
- Your integrators need typed SDKs in
[sdk_languages]for a good day-one experience - You need webhook definitions for
[webhook_events]documented alongside the REST surface - You want reusable schema components instead of duplicated definitions
- You need a Postman collection that matches the spec exactly
- You're standardizing error and rate-limit documentation across
[resource_groups]
Example output
Expect a full OpenAPI 3.1 document organized by [resource_groups], with reusable components, request/response examples, security schemes, webhook definitions for [webhook_events], and discriminated unions for polymorphic payloads. Alongside it you get SDK stubs in each of your [sdk_languages] (with retry and interceptor scaffolding) and an exported Postman collection. It's a contract plus client tooling, not just docs.
Pro tips
- Set
[endpoint_count]and[resource_groups]accurately so the model scopes the spec and doesn't invent endpoints - Treat the OpenAPI file as the source of truth and regenerate SDKs from it whenever the contract changes
- Don't forget
[webhook_events]; async events are the part of an API that's most often left undocumented - Limit
[sdk_languages]to the ones your integrators actually use; each generated SDK is something to maintain - Ask for request and response examples in every endpoint; examples are what make a spec usable, not just valid
- Validate the generated spec with a linter before trusting the SDK output, since codegen quality depends on a clean spec
