Notion 429 request_blocked: stop retrying, keep the Sume result

A Notion 429 with the reason public_api_request_blocked is not a limit you can wait out. Park the write-back, keep the Sume result, and do not resubmit the job.

5 min readSume
All posts

When a Notion write-back for a finished Sume job returns 429 with additional_data.rate_limit_reason set to public_api_request_blocked, stop retrying that request: Notion's request-limits page says access is restricted and retrying will not help, so contact Notion support. Keep the Sume result, park the write-back with the job id and the artifact URLs, and never resubmit the Sume job, which has already completed and been billed.

The Notion details are from its request limits page and the Sume details from Webhooks and Jobs and results, all read 2026-10-03. I did not trigger a blocked response.

Which 429 reasons can I retry?

Notion returns 429 with the error code rate_limited and puts the cause in additional_data.rate_limit_reason. Most reasons are waits: use Retry-After, add exponential backoff with jitter and cap the attempts, which the page puts at about six. The blocked reason is the exception, along with most 400s, a 401 and a 403.

Retry guidance from Notion's request limits page, read 2026-10-03.
SignalMeaningRetry?
public_api_request_rate_limitThis connection sent too fastYes, after Retry-After
public_api_space_request_rate_limitWorkspace shared budget used upYes, after Retry-After
public_api_endpoint_rate_limitA specific endpoint limitYes, after Retry-After
mcp_tool_rate_limitMCP tool limitYes, usually under 10 seconds
public_api_request_blockedAccess restrictedNo, contact support
401 or 403Auth failed or permission blockNo

What should the Sume side do meanwhile?

Acknowledge the Sume webhook with a 2xx as soon as you have durably stored the event, before the Notion call, so the 10-second attempt budget and the 10-attempt cap of job webhooks never depend on Notion's state. Dedupe on job_id. The result stays readable from result_url once result_ready is true, so a parked write-back can be replayed later from your store or by fetching the job again.

Alert a person for the blocked case rather than looping. A write-back queue that retries a blocked request forever fills with work that cannot succeed and hides the jobs that can.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume