Rate limits

The API applies per-workspace rate limits. Limits are shared across all keys in a workspace, so rotating a key does not reset the counter.

Current limits

Bucket	Limit	Notes
Read requests	300 per minute	Applies to every GET.
Write requests	60 per minute	POST, PATCH, DELETE.
Content publish	30 per minute	Only counts POST /content/{id}/publish and cron-triggered scheduled publishes originating from your workspace.
Media uploads	20 per minute	POST /media_assets.

Enterprise plans can request higher ceilings by contacting support.

Rate-limit headers

Every response includes:

X-RateLimit-Limit: 300
X-RateLimit-Remaining: 287
X-RateLimit-Reset: 1747663200

X-RateLimit-Reset is a Unix timestamp (seconds) marking when the current window rolls over.

429 responses

If you exceed a limit, the API returns HTTP 429 with:

{
  "object": "error",
  "type": "rate_limit_exceeded",
  "message": "Too many requests. Retry after the timestamp in X-RateLimit-Reset.",
  "retry_after": 42
}

retry_after is the number of seconds until the next request will succeed. Prefer this value to reading the reset header directly, since it already accounts for jitter.

Recommended client behaviour

• Read X-RateLimit-Remaining on every response, not only on 429s. A well-behaved client should back off proactively when it drops below 10 percent of the ceiling.
• Retry with exponential backoff and jitter on 429 and any 5xx. Base delay of retry_after seconds, cap at 60 seconds.
• Batch where possible. Prefer creating one campaign with 20 posts over 20 separate content requests.
• Do not tight-loop poll. For long-running work like campaigns or scheduled publishes, use webhooks.