Rate Limits
Talonic API rate limits by tier: the Free plan includes a 5,000-credit monthly grant; paid tiers get per-namespace daily request limits and larger file caps.
Talonic API rate limits depend on your API tier, the throughput axis that comes with your Plan. The Free plan is metered by a recurring 5,000-credit monthly grant (no card required) that refreshes each calendar month (UTC). Paid tiers are metered by per-namespace daily request counts that reset at midnight UTC and act as abuse ceilings — actual spend is governed by the credit ledger, so a legitimate workload is bounded by credits, not the daily counter.
Free plan: monthly credit grant
Free workspaces spend from the monthly credit envelope rather than a hard request cap. Requests run until the credit balance is spent, then return 402 INSUFFICIENT_CREDITS until the next grant. Generous daily request ceilings (1,000 extract, 2,000 platform, 1,000 ingest per day) are retained purely as abuse protection and do not bind a legitimate free user within the monthly envelope. Check your balance and reset date with [GET /v1/account](get-account).
Namespaces: how requests are bucketed
Each request is metered against a namespace determined by its path: extract (/v1/extract), ingest (/v1/sources), operations (/v1/process, /v1/runs, /v1/configs), run (POST /v1/run submissions), ask (POST /v1/ask agent turns), and platform (everything else). Poll routes deliberately bill the read platform namespace — GET /v1/run/:id and GET /v1/ask/:id never burn your daily submission quota, so poll as often as your integration needs.
Daily request ceilings by tier
- Free — 5,000 credits/month across all namespaces; daily ceilings (1,000 extract / 2,000 platform / 1,000 ingest) apply only as abuse protection.
- Pro — 25,000 extract, 50,000 platform, 25,000 ingest, 25,000 operations, and 25,000 run submissions per day, plus 5,000 agent asks per day. Sized so corpus-scale bulk ingestion never hits a daily wall; spend is governed by credits.
- Enterprise — Unlimited requests across all namespaces.
A user-scoped individual workspace (personal accounts, not organizations) has much smaller ceilings — 20 extract, 100 platform, and 20 ingest requests per day with a 10 MB file cap — sized for evaluation rather than production traffic. Create an organization workspace before wiring up a real integration.
Maximum file size per tier
- Free — 20 MB per uploaded file.
- Pro — 100 MB per uploaded file.
- Enterprise — 500 MB per uploaded file (the platform maximum).
Uploads over your tier's cap are rejected with 413 FILE_TOO_LARGE before any processing starts, so an oversized file never consumes credits. The error message names the file, its size, and your tier's limit.
Rate limit headers
Whenever a finite daily limit applies to the namespace you called, the response includes rate-limit headers. On Enterprise (and any namespace with an unlimited -1 cap) the headers are omitted entirely, so treat their absence as "unlimited", not as an error:
X-RateLimit-Limit— Daily request cap for the namespace you called.X-RateLimit-Remaining— Requests remaining in the current window.X-RateLimit-Reset— ISO 8601 timestamp when the rate limit window resets (midnight UTC).
Rate limit headers example
HTTP/1.1 200 OK
X-Request-Id: req_3f9a76b19bd948fc
X-RateLimit-Limit: 2000
X-RateLimit-Remaining: 1801
X-RateLimit-Reset: 2026-08-30T00:00:00.000ZWhen the daily count is exhausted, further requests in that namespace return 429 with error: "rate_limit_exceeded" and a details object carrying limit, used, and reset_at. Note that this response reports retryable: false and does not carry a meaningful code — identify it by status and the error label, then sleep until reset_at:
Daily limit exhausted (429)
{
"statusCode": 429,
"error": "rate_limit_exceeded",
"message": "Daily extract request limit (25000) reached. Resets at midnight UTC.",
"retryable": false,
"details": {
"limit": 25000,
"used": 25000,
"reset_at": "2026-08-30T00:00:00.000Z"
},
"request_id": "req_9b1c22e04a5d47aa",
"timestamp": "2026-08-29T14:02:11.481Z",
"path": "/v1/extract"
}To check headroom without making a metered call, use [GET /v1/account](get-account): it returns daily_limits for the extract, platform, ingest, and operations namespaces (-1 means unlimited) alongside usage_today, your credit balance in EUR, and — on the Free plan — the monthly allowance and its next refresh date:
GET /v1/account — limits and usage snapshot
{
"tier": "free",
"status": "active",
"credits": {
"balance": 4210,
"currency": "EUR",
"monthly_allowance": 5000,
"tier_resets_at": "2026-09-01T00:00:00.000Z"
},
"daily_limits": { "extract": 1000, "platform": 2000, "ingest": 1000, "operations": 1000 },
"usage_today": { "extract": 4, "platform": 225, "ingest": 4, "operations": 4 },
"links": {
"self": "/v1/account",
"keys": "/v1/account/keys",
"credits": "/v1/credits/balance",
"upgrade": "/v1/billing/upgrade-link"
}
}POST /v1/run sheds load with 429 INGEST_OVERLOADED or 429 PIPELINE_QUEUE_OVERLOADED when ingest or pipeline capacity is saturated. Those are transient: they set retryable: true and a Retry-After header (~30 s), and they do not consume your daily quota — retry after the interval instead of waiting for midnight.