Notion space rate limit: other apps spend your write-back budget

Notion's limits are per connection and also per workspace, so your Sume write-back worker can receive 429 with the reason public_api_space_request_rate_limit while it is well under its own per-connection rate: the shared workspace budget was spent by everything connected, not by you alone. The response is the same as for the other waits: respect Retry-After, back off with jitter, and cap the attempts.

The numbers are from Notion's request limits page, read 2026-10-03; the Sume numbers are from Webhooks and Generation admission. I did not measure a real workspace.

What are the Notion limits?

Per connection, the page gives 600 requests per minute (an average of 10 per second) for Business and Enterprise workspaces and 180 per minute (an average of 3 per second) for other plans. It adds that a separate per-workspace limit applies across all connections. The budget can be spent at any pace within the 60-second window, and a 529 is treated like a 429.

How does a burst of Sume completions hit it?

Sume runs up to your plan's processing concurrency at once, for example 20 on the Scale plan in its admission table, and each finished job triggers its own webhook. A burst of completions becomes a burst of Notion writes. Put the writes behind a queue with a concurrency cap you choose, take the Retry-After value from the response, and do not retry in the webhook handler itself.

Return 2xx to Sume after storing the event, and let the queue do the Notion work. Sume's job webhooks give you 10 attempts at a fixed 30-second default gap and a 10-second timeout per attempt, so a handler that waits on Notion burns delivery attempts for a problem that has nothing to do with Sume.