Postman Rate Limit and Error Handling Behaviour Review
Check how the API behaves under limits and failures.
The Open buttons send the prompt text as currently shown below to that site only when you click. Fill in the placeholders first.
[VERIFY] is an editorial flag, not a blank to fill. Wherever the prompt shows [VERIFY], check that item against a reliable source before you use it.
Review API behaviour for limits and errors using what Postman tests show. Documented limits and error formats: [DOCUMENTED_LIMITS]. Observed responses for too many requests, invalid input, server errors and timeouts: [OBSERVED_RESPONSES]. Client retry behaviour: [CLIENT_RETRY]. Limit testing to my own non-production service at modest volumes: use a documented small limit and a short burst, not sustained load, and stop at the first limit response; do not suggest overload or attacks. Table of scenarios with Scenario, How to trigger safely, Expected status and headers, Expected body, Observed and Gap, covering invalid JSON, missing required field, wrong type, unauthorised, forbidden, not found, conflict, too many requests and server error. Check consistent status codes and bodies, that rate limit responses say when to retry [VERIFY], and that messages do not leak internals. Separate confirmed gaps from suspicions. Client guideline in five rules, including a retry policy: wait 1 second, then 2, then 4, with a cap of 30 seconds and at most five attempts, honouring any wait time the service returns [VERIFY]; immediate retries make an outage worse. Retry guidance: 429 and 503 yes after waiting, 400 and 404 no. Log each retry with a correlation ID and add a monitoring suggestion.
Fill in before use
Optional: type your details and the prompt above updates. Nothing is saved or sent.
Replace each bracketed placeholder with your own details, then paste into Any AI or another assistant.