Plan rate limits for an API
Prompt that plans request limits for an API, with a method, the response when a limit is exceeded and how to announce it. Paste it into an AI tool of your choice, which then plans the rate limits.
- Topic
- Apps & prototypes
- Type
- Prompt
- Level
- Intermediate
- Time
- about 8 min
Results depend on the tool, the model and what you enter.
Result preview
Example: written by our editors, not real AI output.
Limit per API key (partners use fixed keys, IP addresses change). Limits – Read: 600 requests per minute – Write: 120 requests per minute – Search: 60 requests per minute Method: token bucket, allows short bursts. Drawback: slightly more computation per request. When exceeded: 429, headers RateLimit-Remaining and Retry-After, message "Too many requests. Please try again in 20 seconds." Assumption: peaks of 400 per second are spread across at least ten partners.
Fill in
What you type stays in this browser window. We store and send nothing.
- public REST API for orders
- internal API for our app
- search API with expensive queries
- webhook receiver
- API in front of an AI service
- partner companies with their own key
- only our own app
- paying customers on three plans
- public without sign-in
- internal services
- 50 requests per second on average, peaks of 400
- single accounts send thousands of requests per minute
- no figures yet, launch in three weeks
- load rises sharply on Monday mornings
- search slows down the database
Your prompt
You have edited the prompt. Changes in the fields above no longer overwrite it.
This is an instruction for an AI, not the result itself.
Where this prompt works
These AI tools are a good fit for this prompt:
How to use it
- Fill in the fields or tap a suggestion. Leave out names, addresses and other personal data.
- Copy the finished prompt into an AI tool of your choice.
- First switch the limits on in observe-only mode, which logs breaches but blocks nothing, and adjust them afterwards.
Why does this work?
Going from "limit by what" to "how much" to "what happens then" avoids limits that sound sensible but hit the wrong callers. Headers and clear error messages let callers adapt instead of simply retrying.
Tips
- Expensive endpoints such as search or export usually need their own, lower limits than simple reads.