Limits & Quotas

Every numeric limit Zeridion Flare enforces, on one page. Where a limit varies by plan, the per-tier value is shown. Where a limit is global (the same for every customer), the global value is shown.

For per-endpoint details, see the linked pages. For pricing-tier feature comparison, see the pricing page.

Request rate limits

Every authenticated request counts against a sliding 1-hour window. Exceeding the budget returns 429 rate_limit_exceeded with Retry-After and X-RateLimit-* response headers. See Rate Limits for the response shape.

Plan	Requests per hour
Free	1,000
Starter	5,000
Pro	50,000
Business	500,000
Enterprise	Custom — contact sales

The limit applies to all authenticated endpoints under /flare/v1/* and /platform/v1/*. Health probes (/flare/health/live, /flare/health/ready) are unmetered.

Monthly job allowance

The number of jobs you can create per billing period — your subscription's billing period on paid plans, the calendar month (UTC) on Free. Tracked separately from the request rate limit. When the allowance is exhausted, new job creates return 429 monthly_allowance_exceeded until the period resets — unless opt-in overage is enabled for the project, in which case jobs keep running and the extra volume is metered at your plan's per-10k rate. If you set a spend cap, creates return 429 spend_cap_reached once the cap is reached.

Plan	Jobs per month	Opt-in overage
Free	50,000	—
Starter	300,000	$1.50 / 10k jobs
Pro	3,000,000	$1.00 / 10k jobs
Business	30,000,000	$0.50 / 10k jobs
Enterprise	Custom	Custom

A job that retries does not consume additional allowance — only the first enqueue counts. Track usage via the X-Quota-* response headers on job creation; X-Quota-Reset carries the Unix timestamp of the period end. See Billing → Plans for the full plan comparison and overage details.

Auth-endpoint rate limits

Anonymous endpoints under /platform/v1/auth/* (signup, login, verify, resend, forgot, reset) carry a stricter per-IP cap:

20 requests per 15-minute sliding window per IP — applies to every anonymous auth endpoint regardless of plan.

10 failed attempts per 15-minute sliding window per account → returns 429 account_locked with Retry-After. Resets to 0 on the next successful login.

Signed inbound webhooks (Stripe, SendGrid) are exempt from the per-IP cap. See Authentication § Dashboard auth.

Export cooldowns

Export endpoints carry their own per-project cooldown, independent of the per-hour rate limit:

Endpoint	Cooldown
`POST /flare/v1/jobs/export`	1 export per minute per project
`GET /platform/v1/projects/{id}/audit-log/export`	1 export per minute per project
`GET /platform/v1/account/export`	1 export per minute per user

A second call inside the cooldown window returns 429 rate_limit_exceeded with Retry-After: 60 (the full cooldown window, as a conservative upper bound). The two project-level export buckets are tracked separately — a jobs-export call does not consume the audit-export budget.

The job export window is also capped at 90 days — requests with a wider date span return 400 range_too_large. See Jobs API § Export and Audit Log Export.

Payload caps

Surface	Cap
Job `payload` field	256 KB of raw JSON
Job `tags`	50 entries; key ≤ 64 chars, value ≤ 256 chars
Audit-log `metadata` field	4 KiB

The payload cap is measured on the raw JSON text of the field as sent — there is no compression step, so what you send is what is measured. Exceeding any cap returns 400 validation_error.

Larger payloads should be stored externally (S3, Azure Blob) with the job carrying the URL plus a signed pre-shared token.

Retention windows

Resource	Retained for	Notes
Job history (`succeeded`, `failed`, `cancelled`, `dead_letter`)	90 days	After retention expires, the job row is hard-deleted. Export via jobs export before expiry if you need longer history.
Idempotency replay records	24 hours	After expiry the key is eligible for reuse.
Audit logs	1 year	Export via audit-log/export before expiry if you need longer retention.
Webhook delivery attempts	30 days	The originating job survives retention; only the delivery-attempt record is pruned.
API key metadata (rotated/revoked keys)	30-day grace, then hard-deleted	See Authentication § Key rotation.

Resource caps

Resource	Cap	Notes
Projects per account	1 (Free), 3 (Starter), Unlimited (Pro / Business / Enterprise)	A project is the unit of isolation — separate API keys, separate quotas. Exceeding the cap returns `403 project_limit_reached`.
API keys per project	1 active	Rotating issues a new key and keeps the previous one valid for a 24-hour grace window.
Recurring schedules per project	One per `job_type`	A second schedule reusing a `job_type` returns `409 recurring_job_type_conflict`.
Queues per project	Unlimited	Queues are string-named and created lazily on first use. There is no queue-depth cap.
Continuation chain depth	10 levels	A job continuation chain (parent → child → grandchild) is capped at 10 hops.

Worker concurrency

Worker concurrency is set by the worker process itself — the API does not impose a cap. A single worker can lease as many jobs as its declared max_concurrency allows. The platform allows up to 500 concurrent worker registrations per project before returning 429 worker_limit_exceeded on /workers/register.

Webhook delivery retries

When your webhook receiver returns a 5xx response or fails to respond within 10 seconds per attempt:

Up to 5 delivery attempts total (the initial attempt plus 4 retries) on a fixed backoff schedule: 5 s → 30 s → 5 min → 1 h between attempts.
Total wall-clock time per delivery is roughly an hour (worst case ≈ 66 minutes including per-attempt timeouts) before the delivery is marked failed.
4xx responses are not retried — the delivery is marked failed immediately.

See Webhooks for the full delivery contract and signing scheme.

Request rate limits​

Monthly job allowance​

Auth-endpoint rate limits​

Export cooldowns​

Payload caps​

Retention windows​

Resource caps​

Worker concurrency​

Webhook delivery retries​

See also​