Notion 600 requests/min per connection: write back 100 Sume results

Notion's 2026-09-09 changelog enforces a per-connection limit over a 60-second window: 600 requests per minute on Business and Enterprise plans, 180 on all other plans. A bulk run of 100 Sume items written back one page per request fits under either number, if nothing else shares the connection.

Notion numbers are from its changelog, read 2026-10-01. Sume behavior is from Bulk runs and Run webhooks.

How much of the limit does a 100-item run use?

A bulk run takes 1-100 items. One write per finished item is 100 requests, which is under 180 and under 600. The catch is that the limit is per connection, not per job, so page reads, searches and other writes on the same connection count too.

How do I know when an item is finished?

The bulk queue itself has no webhook. communication.webhook_url is per item, and queue-level progress comes from polling status_url. Each item is a Format run, and its run webhook carries primary_output_url and artifacts on media.sume.com, so the handler can write that URL to the matching Notion page directly. Check the run webhooks payload for the fields your Format returns.

What if the receiver is slow or Notion pushes back?

Return a 2xx after durably storing the event, then do the Notion write from a queue you control, so a 429 from Notion never makes your webhook endpoint fail. Sume retries failed run-webhook deliveries up to 10 attempts in total, so a handler that returns an error because of Notion's limit will be called again. See Notion 504: check the page before retrying.

What should I do first?

Pace writes to well under the plan limit, leave room for other traffic on the connection, and keep a record of which pages are already updated so a redelivery is a no-op. For the single-page version of this flow, see Notion button to webhook to video URL on the page.