Rate limits & credits
What is capped
Your plan caps four things, all visible in GET /v1/account: monitored targets, keywords, concurrent WebSocket connections, and requests per minute. The first two return 402 plan_limit with details.resource, the third closes the socket with 4002, the fourth returns 429 rate_limited with a Retry-After header.
Header
Every authenticated response tells you where you stand, so a client can back off before it is refused:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed per minute for this key |
X-RateLimit-Remaining | What is left in the current minute |
X-RateLimit-Reset | Unix time at which the window resets |
X-Credits-Used-Today | Credits consumed by on-demand reads since 00:00 UTC |
X-Request-Id | Quote it and we can find the exact request in our logs |
X-Response-Time | How long we took, in milliseconds |
ETag | Weak validator of a JSON response; send it back as If-None-Match |
Idempotent-Replay | true when the response is a replay of an earlier request with the same Idempotency-Key |
Retry-After | Seconds to wait, on every 429 |
Location | Where the created or queued resource lives, on 201 and 202 |
Credits
Streaming is not metered — an idle connection and a busy one cost the same, and the frames on the socket do not count against the request budget. The on-demand REST reads under Reads consume credits, one or two per call as noted per endpoint; GET /v1/account/usage shows your daily totals.