API Endpoint Implementation Blueprint

The Prompt

You are a senior backend engineer. Produce a production-ready implementation blueprint for an API endpoint in {{language}} using {{framework}}.

Endpoint contract:
{{endpoint_contract}}

Authentication and authorization requirements:
{{auth_requirements}}

Error model and response conventions:
{{error_model}}

Return output in this exact order:
1) Endpoint summary (method, route, purpose)
2) Request schema and validation rules
3) AuthN/AuthZ flow and failure handling
4) Handler pseudocode with key branches
5) Data access and transaction considerations
6) Error responses (status, code, message contract)
7) Test plan (unit, integration, and auth edge cases)
8) Observability hooks (logs, metrics, trace points)

Constraints:
- Follow least-privilege auth decisions.
- Validate all external input before business logic.
- Keep error payloads consistent and non-leaky.
- Identify idempotency, race conditions, and retry behavior.

When to Use

Use this prompt when you need a clear endpoint implementation plan before coding. It is especially useful for teams that want consistent API quality across authentication, validation, and error handling.

Great fit for:

• New CRUD endpoints with non-trivial validation
• Endpoints with role- or scope-based access control
• Payment or workflow operations that need idempotency
• Legacy APIs being standardized for consistent error contracts

Instead of jumping directly to code, this prompt gives you an implementation blueprint that aligns architecture, security, and test coverage first.

Variables

Variable	Description	Good input examples
language	Backend language	TypeScript, Python, Kotlin
framework	Server framework used in the project	Fastify, Express, Django, Spring Boot
endpoint_contract	Route, method, request/response shape	”POST /v1/orders with lineItems[] and shippingAddress”
auth_requirements	Auth method and access rules	”JWT required, scope=orders:write, admin override allowed”
error_model	Standardized error payload and codes	RFC7807 variant, internal code map, localization rules

Tips & Variations

• Add “multi-tenant constraints” if tenant isolation is required.
• Ask for “OpenAPI schema draft” to generate docs-ready contracts.
• If PII is involved, request a data classification section.
• Add “rate limit policy” when endpoint abuse is a concern.
• After planning, run a follow-up prompt: “Generate starter code from this blueprint.”

For consistent team output, keep your error_model variable aligned with your existing platform conventions.

Example Output

Request validation: reject unknown fields, require customerId, enforce max 50 lineItems.

Auth flow: verify JWT, require orders:write, deny cross-tenant resource access.

Error contract: 409 ORDER_ALREADY_EXISTS for idempotency conflict, no stack traces in response.

Test case: integration test for expired token returns 401 with standardized error payload.