30 Claude Prompts That Build APIs

You are a backend engineer implementing distributed rate limiting. <context> I need token-bucket rate limiting backed by Redis so it works across multiple app instances, returned as one self-contained, commented code block. </context> <inputs> - Stack and Redis client: [EXPRESS + IOREDIS / FASTAPI + REDIS-PY] - Limit key: [PER API KEY / PER IP / PER USER] - Rate: [E.G. 100 REQUESTS PER MINUTE, BURST 20] - Scope: [GLOBAL / PER ENDPOINT] </inputs> <task> Build middleware that runs a Redis Lua script implementing the token-bucket algorithm atomically (refill by elapsed time, consume one token, return allowed + remaining). Set X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers on every response, and return 429 with a Retry-After header when the bucket is empty. </task> <constraints> - The check-and-decrement must be atomic (Lua script or equivalent) to avoid race conditions across instances. - Emit standard rate-limit headers and Retry-After; fail OPEN or CLOSED explicitly (state which and why) if Redis is down. - Valid, runnable code including the Lua script with comments. </constraints> <format> Return the middleware plus the Lua script as a code block, then explain the atomicity guarantee and the fail-open/closed choice. </format>

You are a backend engineer who needs smoother rate limiting than fixed windows. <context> Fixed windows let bursts double the limit at boundaries. I need a sliding-window (log or weighted) rate limiter, returned as one self-contained, commented code block. </context> <inputs> - Stack and store: [REDIS / IN-MEMORY] - Algorithm preference: [SLIDING WINDOW LOG / SLIDING WINDOW COUNTER] - Rate and window: [E.G. 60 REQUESTS PER 60s] - Key: [IP / USER / KEY] </inputs> <task> Build the limiter implementing the chosen sliding-window algorithm: for the log variant, store request timestamps in a sorted set, trim entries outside the window, count, and add the new one atomically; for the counter variant, blend the current and previous window counts by elapsed fraction. Return allowed + remaining + reset and set 429 with Retry-After when exceeded. </task> <constraints> - Explain the boundary-burst problem the sliding window fixes in a comment. - Atomic operations only; bound memory (trim old entries / expire keys). - Valid, runnable code with the standard rate-limit response headers. </constraints> <format> Return the limiter as a code block, then contrast its accuracy and memory cost against the token-bucket approach in 3-4 lines. </format>

You are a backend engineer optimizing API response caching at the HTTP layer. <context> I want clients and proxies to cache my GET responses correctly using ETags and conditional requests, returned as one self-contained, commented code block. </context> <inputs> - Stack: [EXPRESS / FASTAPI] - Resource being served: [DESCRIBE] - Freshness policy: [E.G. PRIVATE, max-age 60, must-revalidate] - ETag basis: [CONTENT HASH / updatedAt VERSION] </inputs> <task> Build a GET handler that computes a strong or weak ETag, sets Cache-Control and Last-Modified, and honors If-None-Match / If-Modified-Since by returning 304 Not Modified with no body when the client's copy is current. Do the same for a mutation returning 412 on a failed If-Match (optimistic concurrency). </task> <constraints> - Correct 304 (empty body, ETag preserved) and 412 semantics; choose strong vs weak ETag and justify it. - Cache-Control directives must match the data's real freshness (no caching private data as public). - Valid, runnable code with comments on each header's effect. </constraints> <format> Return the handler as a code block, then a curl sequence showing a 200 then a 304 on the second request. </format>

You are a backend engineer adding a caching layer to slow read endpoints. <context> I need a reusable cache-aside helper that wraps expensive reads with Redis, handling misses, TTLs, and invalidation, returned as one self-contained, commented code block. </context> <inputs> - Stack and Redis client: [DESCRIBE] - Endpoints to cache: [E.G. GET /products/:id, GET /reports/summary] - TTL and staleness tolerance: [E.G. 300s] - Invalidation triggers: [ON WRITE TO RESOURCE X] </inputs> <task> Build a cached(key, ttl, fetchFn) helper: on hit, return parsed value; on miss, call fetchFn, store the result, and return it. Add namespaced key builders, a delPattern invalidation helper called from write paths, and single-flight/lock to prevent a cache stampede when many requests miss the same key at once. Show it wrapping one read endpoint and being invalidated by its write. </task> <constraints> - Prevent stampede (lock or single-flight) on hot-key misses; jitter TTLs to avoid synchronized expiry. - Never cache errors or partial results; namespace keys so invalidation is targeted. - Valid, runnable code with comments on the stampede protection. </constraints> <format> Return the helper plus a wrapped endpoint and its invalidation as a code block, then note what should never be cached. </format>

You are a backend engineer building metered API usage for a paid product. <context> I need per-API-key monthly quotas with usage counting and quota-exceeded responses, returned as one self-contained, commented code block. </context> <inputs> - Stack and store: [REDIS / POSTGRES] - Plans and limits: [E.G. free: 1k/mo, pro: 100k/mo] - Counting unit: [REQUESTS / CREDITS PER ENDPOINT] - Reset cadence: [CALENDAR MONTH / ROLLING 30d] </inputs> <task> Build middleware that resolves the caller's plan, atomically increments their usage counter for the current period, compares against the plan limit, sets X-Quota-Limit / X-Quota-Used / X-Quota-Reset headers, and returns 429 with an upgrade hint when exceeded. Include a GET /usage endpoint so customers can see their current consumption, and a period-key scheme that auto-resets. </task> <constraints> - Atomic increment (avoid lost updates under concurrency); period key encodes the reset boundary so it resets automatically. - Distinguish rate limiting (short-term) from quota (billing-period) clearly in comments. - Valid, runnable code with the usage data model. </constraints> <format> Return the middleware plus the /usage endpoint as a code block, then a table mapping plans to limits and the reset logic. </format>

You are a TypeScript backend engineer who validates every request at the edge. <context> I need reusable validation middleware that checks body, query, and params against Zod schemas and returns clean 400s, returned as one self-contained, commented code block. </context> <inputs> - Framework: [EXPRESS / FASTIFY / NEXT ROUTE HANDLER] - A sample endpoint to validate: [E.G. POST /users with email, password, age] - Error shape I want: [FIELD -> MESSAGE MAP / RFC 9457] - Coerce query strings to numbers/booleans: [YES / NO] </inputs> <task> Build a validate({ body, query, params }) middleware factory that parses each part with its Zod schema, and on failure returns 400 with a structured list of field errors (path + message). On success, replace req values with the parsed, typed data so handlers get clean types. Show it applied to the sample endpoint with its schema. </task> <constraints> - Return ALL validation errors at once, not just the first; include the field path for each. - Strip unknown keys; coerce where asked; never let unvalidated data reach the handler. - Valid, runnable TypeScript with inferred handler types from the schema. </constraints> <format> Return the middleware plus the sample schema and route as a code block, then show an example 400 response body. </format>

You are a backend engineer standardizing API errors to a spec. <context> I want all errors returned as application/problem+json per RFC 9457, from one centralized handler, returned as a self-contained, commented code block. </context> <inputs> - Stack: [EXPRESS / FASTAPI] - Custom error classes I have (if any): [LIST OR NONE] - Base URL for problem type URIs: [E.G. https://api.example.com/problems] - Include stack traces in dev only: [YES] </inputs> <task> Build an AppError base (with type, title, status, detail, and optional extensions) plus a few subclasses (NotFound, Validation, Unauthorized, Conflict), and a central error-handling middleware that serializes any thrown error to a problem+json body { type, title, status, detail, instance } with the right Content-Type. Map unknown errors to a generic 500 without leaking internals. </task> <constraints> - Content-Type application/problem+json; never leak stack traces or DB errors to clients in production. - Every error has a stable, documentable type URI; validation errors include an errors[] extension member. - Valid, runnable code; a single place converts errors to responses. </constraints> <format> Return the error classes plus the handler as a code block, then show two example problem+json responses (404 and validation 422). </format>

You are a Python API engineer who enforces strict, meaningful input rules. <context> I need Pydantic v2 models with custom validators and clean 422 error formatting for a specific payload, returned as one self-contained, commented code block. </context> <inputs> - Payload and rules: [E.G. signup: email valid, password >=12 with mixed case, age 13-120, referralCode optional pattern] - Cross-field rules: [E.G. endDate must be after startDate] - Framework: [FASTAPI / STANDALONE PYDANTIC] - Error format: [DEFAULT / CUSTOM FLAT MAP] </inputs> <task> Build the model(s) with field constraints (types, ranges, patterns), field_validators for single-field rules, and a model_validator for cross-field rules. If FastAPI, add an exception handler that reshapes RequestValidationError into a clean { field: message } map. Include examples of both a passing and a failing payload. </task> <constraints> - Use Pydantic v2 syntax; validators must raise clear, user-facing messages (not internal jargon). - Cross-field checks go in a model_validator(mode="after"); no rules duplicated in the endpoint. - Valid, runnable code with comments on each rule. </constraints> <format> Return the models plus the handler as a code block, then show the exact 422 body for the failing payload. </format>

You are an API designer defining a single error contract for all clients. <context> I want every error response to share one JSON envelope with a machine-readable code, so front-end and SDK code can handle errors uniformly. Return one self-contained, commented code block plus the code catalog. </context> <inputs> - Stack: [DESCRIBE] - Envelope shape preference: [E.G. { error: { code, message, details, requestId } }] - Known error scenarios: [E.G. AUTH_REQUIRED, FORBIDDEN, NOT_FOUND, VALIDATION_FAILED, RATE_LIMITED, CONFLICT] - Correlation id source: [HEADER / GENERATED] </inputs> <task> Build an error catalog mapping each code to an HTTP status and a default message, a helper that builds the envelope (attaching a requestId for tracing), and a central handler that turns thrown errors into the envelope. Ensure every non-2xx path uses it. Include the requestId in a response header too. </task> <constraints> - One envelope for ALL errors; codes are stable and never reused for different meanings. - Always include a requestId clients can quote in support tickets; messages are safe to show users. - Valid, runnable code with the full code-to-status catalog as the single source of truth. </constraints> <format> Return the catalog plus the handler as a code block, then a table of every error code, its status, and when to use it. </format>

You are a payments-grade backend engineer preventing duplicate writes. <context> I need Idempotency-Key support on unsafe POST endpoints so retried requests do not double-charge or double-create, returned as one self-contained, commented code block. </context> <inputs> - Stack and store: [EXPRESS + REDIS / FASTAPI + POSTGRES] - Endpoint to protect: [E.G. POST /payments, POST /orders] - Key TTL: [E.G. 24h] - Request-fingerprint check: [YES / NO] </inputs> <task> Build middleware that reads the Idempotency-Key header: if unseen, acquire a lock, process the request, and store the response (status + body) keyed by the idempotency key; if seen and completed, replay the stored response without re-executing; if seen but in-flight, return 409 (or wait). Optionally verify the request body matches the original fingerprint and reject reuse of a key with a different payload. </task> <constraints> - Store and replay the exact original response; guard concurrent duplicates with a lock, no check-then-act gap. - Detect a reused key carrying a different body and return 422; expire keys after the TTL. - Valid, runnable code with the idempotency record model and comments on the concurrency path. </constraints> <format> Return the middleware plus the record model as a code block, then walk through what happens on a client retry after a network timeout. </format>

You are an API architect who writes precise OpenAPI specifications. <context> I need a complete, valid OpenAPI 3.1 spec for my API from a plain-English description, returned as one self-contained YAML document I can paste into Swagger Editor. </context> <inputs> - API purpose and base URL: [DESCRIBE + https://api.example.com/v1] - Resources and operations: [E.G. users (CRUD), sessions (login/logout), reports (read)] - Auth scheme: [BEARER JWT / API KEY / OAUTH2] - Key request/response fields per resource: [DESCRIBE] </inputs> <task> Write the full spec: openapi 3.1.0, info, servers, a securitySchemes entry and a global security requirement, paths for every operation with parameters, requestBody, and responses (including 400/401/404/429 where relevant), and reusable components/schemas with types, formats, required arrays, and examples. Reference schemas with $ref rather than repeating them. </task> <constraints> - Must be valid OpenAPI 3.1 that passes a linter; no dangling $refs; realistic examples on schemas. - Reuse schemas via components; include error response schema; document pagination params if listing. - Return YAML, correctly indented, in one block. </constraints> <format> Return the complete OpenAPI YAML as a code block, then a short note on validating it and generating a client SDK from it. </format>

You are an engineer who documents existing APIs accurately. <context> I will paste my route/handler code and you will reverse-engineer a faithful OpenAPI 3.1 spec from it, returned as one self-contained YAML document. </context> <inputs> - Framework: [EXPRESS / FASTAPI / FLASK / OTHER] - The route + handler code: [PASTE] - Auth mechanism used: [DESCRIBE] - Base URL: [URL] </inputs> <task> Read the code and produce paths for every route you find, inferring path/query/body parameters, request and response schemas from the validation and the objects returned, status codes actually used, and the security scheme. Flag anything ambiguous in comments rather than inventing it, and add examples derived from the code. </task> <constraints> - Only document what the code actually does; mark inferred-or-uncertain parts explicitly, do not fabricate endpoints or fields. - Valid OpenAPI 3.1 that lints clean; schemas reused via components. - Return YAML in one block. </constraints> <format> Return the OpenAPI YAML as a code block, then list any endpoints or fields you could not fully determine from the code so I can confirm them. </format>

You are a developer-experience engineer who ships great API onboarding. <context> I need a ready-to-import Postman collection (v2.1) for my API so teammates can call every endpoint immediately, returned as one self-contained JSON document. </context> <inputs> - API base URL and auth: [URL + BEARER/API KEY] - Endpoints (or paste an OpenAPI spec): [LIST OR SPEC] - Environment variables to use: [E.G. {{baseUrl}}, {{token}}] - Sample data for bodies: [DESCRIBE] </inputs> <task> Generate a Postman v2.1 collection: folders per resource, a request per operation with method, {{baseUrl}}-based URL, headers, and example JSON bodies; collection-level auth using a {{token}} variable; and a small test script on the login request that saves the returned token into an environment variable so later requests are authenticated automatically. Include a companion environment file. </task> <constraints> - Valid Postman Collection Format v2.1 JSON that imports without errors; use variables, never hardcoded secrets. - Include realistic example bodies and at least one test script that chains auth. - Return the collection and the environment as two JSON blocks. </constraints> <format> Return the collection JSON and environment JSON as separate code blocks, then note the import steps and how the token auto-populates. </format>

You are a technical writer who turns specs into developer-friendly docs. <context> I have an OpenAPI spec and need a clean, human-readable Markdown API reference from it, returned as one self-contained Markdown document. </context> <inputs> - The OpenAPI spec (or endpoint list): [PASTE] - Audience: [EXTERNAL DEVS / INTERNAL TEAM] - Include code samples in: [CURL + JS FETCH + PYTHON] - Tone: [CONCISE REFERENCE / TUTORIAL-ISH] </inputs> <task> Write the reference: an intro (base URL, auth, how to get a key), a conventions section (pagination, errors, rate limits), then one section per endpoint with method + path, a one-line purpose, a parameters table (name, in, type, required, description), request and response body examples, status codes, and copy-paste code samples in each requested language. </task> <constraints> - Accurate to the spec; every parameter and status code documented; realistic example values. - Code samples must actually run against the described API (correct headers, auth, body). - Return valid Markdown with tables and fenced code blocks in one document. </constraints> <format> Return the full Markdown reference in one block, then note which sections to keep in a separate "Getting Started" page. </format>

You are a backend engineer who unblocks frontend teams before the API is built. <context> I need a runnable mock server that serves realistic example responses for my endpoints so the frontend can build in parallel, returned as one self-contained, commented code block. </context> <inputs> - Endpoints (or paste OpenAPI spec): [LIST OR SPEC] - Stack for the mock: [EXPRESS / FASTAPI / JSON-SERVER STYLE] - Behaviors to simulate: [LATENCY, RANDOM 500s, AUTH REQUIRED, PAGINATION] - Realistic sample data theme: [E.G. USERS, PRODUCTS] </inputs> <task> Build a mock server that implements each route returning schema-accurate example JSON, supports the requested behaviors (configurable latency, an optional random-error rate, a fake auth check that 401s without a token, and working pagination over an in-memory dataset), and reads a flag to toggle chaos on/off. Seed a small realistic dataset so responses feel real. </task> <constraints> - Responses must match the real API's shapes and status codes so the frontend can code against them safely. - Toggleable latency and error injection; clearly marked as a mock (no real persistence). - Valid, runnable code with a one-command start and the seed data included. </constraints> <format> Return the mock server as a code block, then note the start command, how to toggle chaos, and how to swap it for the real API later. </format>