StickyTier

The limit

10 requests per second per key, with a burst of 50. A token bucket: you can spend up to 50 at once, and it refills at 10 a second. A batch of events costs one token per 10 events (a batch of 100 costs 10), which keeps batches the efficient way to send history without letting one key push a thousand events a second.

The headers

Every response carries:

X-RateLimit-Limit: 50
X-RateLimit-Remaining: 37
X-Request-Id: req_2b227f33ebe04775ba04c1483397de13

When you are over the limit:

HTTP/1.1 429 Too Many Requests
Retry-After: 1
Content-Type: application/problem+json

{ "type": "https://stickytier.com/docs/api/errors#rate-limited", "status": 429, "retry_after": 1 }

Backlog shedding

Accepting an event is cheap; processing it is not. If a programme has more than 20,000 events waiting, new events are refused with 429 and reason: "backlog" until the queue drains. Nothing is accepted in that state, so the events are safe to resend — that is what idempotency keys are for.

Practical advice

Send history in batches of 100, not one call per order.
Poll GET /v1/events?status=failed a few times an hour, not every second; subscribe to webhooks for the live signal.
GET /v1/tenant/liability is cached for 30 seconds; polling it faster returns the same figure.
Treat X-RateLimit-Remaining under 10 as a signal to slow down before you hit 429.
A higher limit for a specific key is a support request.