Rate limits

The Featurebase API limits how many requests your workspace can send per minute. The limits keep the API fast and reliable for everyone.

Limits

• 3,000 requests per minute per workspace. All API keys, OAuth apps and AI connectors (MCP) of a workspace share this limit.

• 2,000 requests per minute per API key or connection. One integration can never use the whole workspace limit, so your other integrations keep working.

• A few endpoints have their own, lower limits (for example, creating many posts at once). The error tells you which limit you reached.

The limits are the same on every plan. Using the Featurebase dashboard, widgets, portal or help center does not count toward your API limit.

Each limit counts requests in one-minute windows. When you go over a limit, the API refuses requests only until the current window ends. There is no lockout.

Requests from one IP address also have a much higher limit that stops traffic floods. Normal integrations never reach it.

Response headers

Every response to a request with a valid API key or token includes these headers:

• X-RateLimit-Limit: the number of requests allowed per minute.

• X-RateLimit-Remaining: the number of requests left in the current window.

• X-RateLimit-Reset: when the current window ends, as a Unix timestamp in seconds.

When the workspace limit and the key limit both apply, the headers show the one with fewer requests left.

When you reach a limit

The API returns HTTP 429 Too Many Requests with a Retry-After header (in seconds) and this body:

{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limited",
    "message": "Rate limit exceeded: 3000 requests per 60 seconds per workspace. Retry in 12 seconds.",
    "details": { "lane": "api", "scope": "workspace", "limit": 3000, "windowSeconds": 60 }
  },
  "retryAfter": 12
}

details.scope tells you which limit you reached:

• workspace: the limit for your whole workspace.

• connection: the limit for one API key or connection.

• ip: the flood limit for one IP address.

Best practices

• Wait for the number of seconds in Retry-After before you send the next request. Add a small random delay if you run many workers.

• Use webhooks to learn about changes instead of polling.

• Use list endpoints with a cursor instead of fetching items one by one.

• Spread large imports and syncs over time instead of sending them in one burst.

Need a higher limit?

Contact us through the Messenger with your workspace name and what you need the higher limit for.