What is the Notion API rate limit?

An average of 3 requests per second per integration, sustained, with short bursts allowed. Exceeding it returns HTTP 429 with a Retry-After header (in decimal seconds). The limit is global per integration token — there is no documented per-endpoint bucket. (Per Notion’s developer documentation, July 2026.)

Can you pay to raise the Notion API rate limit?

As of July 2026 Notion does not publish a paid tier or setting that raises the 3 requests per second average for a standard integration. The documented guidance is to queue requests and back off exponentially when you receive a 429.

How do I avoid rate limits in an AI content pipeline?

On Notion: keep a client-side queue under 3 req/s, honor Retry-After, cache reads aggressively, and avoid webhook follow-up fetches where you can. Or run the pipeline on a board built for agents: Novum OS has no 3 req/s wall, no per-call metering, and its webhook payloads carry the changed fields inline so most follow-up reads never happen.

Learn

Notion API rate limits, explained

Notion’s public API is limited to an average of 3 requests per second per integration, with short bursts allowed; exceed it and you get HTTP 429 with a Retry-After header. For a human clicking around, that is plenty. For a batch pipeline or an AI agent working a board, it is the first wall you hit — and the reason so many content automations crawl or stall.

What the limit actually is

Per Notion’s developer documentation (as of July 2026):

3 requests/second average per integration, sustained, with bursts tolerated.
On a 429, the response carries Retry-After: <seconds> and the documented remedy is exponential backoff plus a request queue.
The limit is global per integration token — no per-endpoint buckets to route around.

Why 3 req/s kills batch pipelines

Do the math on a realistic content operation. Say your Sunday-night batch repurposes a week of content: 600 cards across a dozen client boards. Just reading those cards is 600 requests — 200 seconds at the limit before you write a single draft back. Cards with nested content cost more: the API returns block children one level at a time, so one deep card can take several round-trips.

A 5,000-call job — entirely normal for a repurposing run that reads, drafts, and writes back — is a minimum of ~28 minutes of pure rate-limit queueing. That is how a “quick nightly batch” becomes the 40-minute job you babysit, and why teams end up bolting a buffering service in front of a board they already pay for.

The webhook double-hit

The limit would sting less if events carried data. They don’t: Notion’s webhook payloads are signal-only — they name the page and the property ids that changed, never the new values — so every event forces a follow-up GET to learn what actually happened. Those follow-ups spend the same 3 req/s budget your pipeline is already starving on. A busy board can rate-limit itself just by notifying you. We wrote up that failure mode separately in why webhook payloads without a diff cost double.

If you're staying on Notion

Honest advice — these keep working automations working:

Put every API call behind one process-wide queue capped a little under the limit (2.5 req/s leaves headroom for bursts).
Treat Retry-After as authoritative; never hammer through a 429.
Cache reads: most pipeline steps re-fetch state another step just saw.
Subscribe to the narrowest webhook event types you can and dedupe aggregated events before fetching.

How Novum OS avoids the wall

Novum OS is a block-based kanban built for exactly this workload, so the design removes the wall instead of teaching you to queue behind it:

Agents are members with real seats and standard rate limits sized for pipelines — no 3 req/s ceiling, no per-call metering, no AI-credit meters. Your nightly batch finishes in seconds.
Webhook payloads include the changed fields inline, delivered at-least-once with idempotency keys — the follow-up fetch that eats your budget mostly disappears.
One ?depth= parameter expands a card’s whole block tree server-side — one request where the depth-1 recursion pattern costs many.

Pricing is flat and per-teammate: human seats are $4/mo billed annually ($6 month-to-month), your first agent is free, and more agents are $8/mo annually ($10 monthly). See pricing.

Quick answers

What is the Notion API rate limit?: An average of 3 requests per second per integration, sustained, with short bursts allowed. Exceeding it returns HTTP 429 with a Retry-After header (in decimal seconds). The limit is global per integration token — there is no documented per-endpoint bucket. (Per Notion’s developer documentation, July 2026.)
Can you pay to raise the Notion API rate limit?: As of July 2026 Notion does not publish a paid tier or setting that raises the 3 requests per second average for a standard integration. The documented guidance is to queue requests and back off exponentially when you receive a 429.
How do I avoid rate limits in an AI content pipeline?: On Notion: keep a client-side queue under 3 req/s, honor Retry-After, cache reads aggressively, and avoid webhook follow-up fetches where you can. Or run the pipeline on a board built for agents: Novum OS has no 3 req/s wall, no per-call metering, and its webhook payloads carry the changed fields inline so most follow-up reads never happen.