Skip to main content
The Spotzee API enforces per-source-IP rate limits at the edge today. Two rules apply across apix.spotzee.com. Requests to /api/client/* count towards both limits. Either rule can block an IP, depending on its traffic. Both rules count matching requests from each source IP, authenticated or not.

Response on a block

Over-limit requests receive 429 Too Many Requests with this JSON body:

Retry strategy

1

Honour Retry-After when present

If the response includes Retry-After, wait at least that long before retrying. Otherwise, use exponential backoff. Another request can still receive 429 while a block remains active.
2

Add jitter when fanning out

If you’re driving many requests in parallel from a single host, add 0–500 ms of jitter on top of your delay so retries don’t synchronise.
3

Back off on repeats

If you see a second 429, honour Retry-After when present. Otherwise, double your delay (exponential backoff) up to a sensible cap, for example 60 seconds.
4

Cap concurrency per IP

Both limits count by source IP. Outbound traffic from a single host is the one to pace.

Self-throttling example

Quota-metered endpoints

The Extended API meters certain operations separately from request rate limits. Insufficient credits can return 402 even when request capacity remains available. Check your balance in the Spotzee app before high-volume runs; no public Quota endpoint appears in the generated Extended API reference.

Rolling out

Per-key read/write budgets, X-RateLimit-* headers and a doubled MCP budget depend on rollout availability. Do not use them to exceed the per-IP limits or assume that setting a client-type header grants extra capacity. The self-throttling pattern (honour Retry-After when present, add jitter, exponential backoff) works against either layer.

Next steps

Idempotency

Make retries safe.

Errors

Status codes and the code catalogue.