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, with 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: NovumOS 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 it is why so many content automations crawl or stall.

What the Notion API rate limit 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. There are 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, or 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 repurposing run that reads, drafts, and writes back can easily make 5,000 calls. That is a minimum of ~28 minutes of pure rate-limit queueing. This 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, but Notion’s webhook payloads are signal-only. They name the page and the property ids that changed but never the new values, so every event forces a follow-up GET to learn what 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

These habits 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 NovumOS avoids the wall

NovumOS is a block-based kanban built for 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. There is no 3 req/s ceiling, per-call metering, or AI-credit meter, so your nightly batch finishes in seconds.
Webhook payloads include the changed fields inline, delivered at-least-once with idempotency keys, so the follow-up fetch that eats your budget mostly disappears.
One ?depth= parameter expands a card’s whole block tree server-side, in one request where the depth-1 recursion pattern costs many.

Pricing is flat and per-teammate: every seat is $1/mo billed annually ($3 month-to-month) for humans and agents alike, and your first agent is free. 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, with 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: NovumOS 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.