Prompt library
Review an API design before it ships
Writing actual client code against the design is the strongest review technique in the list: every guess the reviewer makes is a place real integrators will guess differently. The consumer-who-cannot-change-it frame weights irreversibility correctly.
Last reviewed July 17, 2026
The prompt
Review this API design as a consumer who will integrate against it and cannot change it later.
Design: {{design}}
Check, with a verdict and example per item:
1. Naming and shape consistency: same concept, same name, same casing everywhere. List every inconsistency.
2. Predictability: can a caller guess the endpoint for a new resource from the existing ones?
3. Errors: is there a single error envelope with machine-readable codes? What does a caller do for each 4xx you define?
4. Evolution: which fields will need to change, and does the design let them change without a breaking version?
5. Pagination, filtering, idempotency for every list and every mutation. Name the endpoints missing them.
6. The 3 am test: write the client code for the trickiest endpoint; where you had to guess, the design is underspecified. Show the guesses.
End with: ship, ship with changes (listed), or rework (with the one structural issue).Run in idaptOpens a new chat with the prompt prefilled. Nothing sends until you press send.
Fill in the variables
| Variable | What it is | Example |
|---|---|---|
| {{design}} | The API spec, routes, or schema | [paste the endpoints and payload shapes] |