Rate limits

Per-workspace and per-operation limits, headers, and retry behavior for agent workflows and HTTP calls.

UnifAPI enforces two layers of rate limiting: a per-workspace limit that smooths traffic across all Skills and API calls, and a per-operation limit that protects each public-data source.

Headers

Every response — 2xx or 429 — carries the standard headers:

Header	Meaning
`X-RateLimit-Limit`	Requests allowed in the current window
`X-RateLimit-Remaining`	Requests left in the current window
`X-RateLimit-Reset`	Unix timestamp (seconds) when the window resets
`Retry-After`	Seconds to wait before retrying (`429` only)

When both a workspace and an endpoint limit apply, the headers report whichever is tighter.

Defaults

Plan	Workspace limit	Per-endpoint limit
Free	60 req/min	Source-aware
Pay-as-you-go	600 req/min	Source-aware
Enterprise	Custom	Custom

Handling `429`

async function call(url: string, init: RequestInit, attempt = 0): Promise<Response> {
  const res = await fetch(url, init);
  if (res.status !== 429 || attempt >= 5) return res;

  const retryAfter = Number(res.headers.get("Retry-After") ?? 1);
  await new Promise((r) => setTimeout(r, retryAfter * 1000));
  return call(url, init, attempt + 1);
}

Two rules to live by:

Honor Retry-After. UnifAPI returns the wait time the operation needs — guessing usually makes things worse.
Back off on repeated 429s. If a Skill hits the limit several times in a row, narrow the query, reduce concurrency, or increase the workspace limit.

Burst behavior

Limits are token-bucket: a workspace that has been idle for a minute can briefly burst above its steady-state limit. Don't rely on this for production traffic — design for the steady-state rate.

Asking for more

Need a higher limit? Email support@unifapi.com with your workspace ID, the Skill or operation you are running, and a rough QPS estimate.