Rate limits
Aztec-Calcs limits how many requests each cobrand can make a minute. The limit keeps the service fair for every customer and stops abuse.
Before you start
The limits count requests per cobrand and per kind of key:
| Counted against | Applies to | Limit |
|---|---|---|
| Your secret key | The REST calculation API and the MCP endpoint, together | 600 requests a minute |
| Your public key | The embed endpoints, together with the hosted pages, which load their calculators through those endpoints | 1,200 requests a minute |
| Calculator link beacons | The call-to-action events that embedded and hosted calculators send | 600 requests a minute, counted apart from the other limits |
The window slides over the last 60 seconds. A request that fails authentication, or comes from a domain that isn't allowed, doesn't count against your limit.
Minimal example
When you go over a limit, the response is 429 Too Many Requests with the code rate_limited and a Retry-After header. The header holds the number of seconds to wait, as a whole number of at least 1.
export AZTEC_API_HOST="<your API host>"
export AZTEC_SECRET_KEY="<your secret key>"
curl -sS -i "https://$AZTEC_API_HOST/v1/calculators" \
-H "Authorization: Bearer $AZTEC_SECRET_KEY"
If your key is over its limit, the response looks like this:
HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/problem+json
{"type":"https://errors.azteccalcs.com/calculation-api/rate_limited","title":"Too many requests","status":429,"detail":"The cobrand's request limit was exceeded. Try again shortly.","code":"rate_limited","traceId":"4bf92f3577b34da6a3ce929d0e0e4736"}
Wait for the Retry-After time before you send the next request.
Options
There are no options to set. The limits apply to every cobrand the same way, and you can't raise them for one cobrand. To stay under a limit, cache results on your side and send a calculation only when the inputs change.
Errors and limits
| Surface | Status | code | Extra |
|---|---|---|---|
| REST calculation API | 429 | rate_limited | Retry-After header |
| MCP endpoint | 429 | rate_limited | Retry-After header; the body is a problem document, not a JSON-RPC message |
| Embed endpoints | 429 | rate_limited | Retry-After header; the error carries the CORS header, so a browser can read it |
- The responses carry no other rate-limit headers.
- Calls without a valid key never use a cobrand's limit.
- If the limiter itself fails, the request goes through. This is the same on the REST API, the MCP endpoint and the embed endpoints, which share one limiter.
- The platform sets the values above in its service configuration. You can't change them for your cobrand, and they can change in the future. Check this page for the current values.