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.

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.
| Signal | Meaning | Retry? |
|---|---|---|
public_api_request_rate_limit | This connection sent too fast | Yes, after Retry-After |
public_api_space_request_rate_limit | Workspace shared budget used up | Yes, after Retry-After |
public_api_endpoint_rate_limit | A specific endpoint limit | Yes, after Retry-After |
mcp_tool_rate_limit | MCP tool limit | Yes, usually under 10 seconds |
public_api_request_blocked | Access restricted | No, contact support |
401 or 403 | Auth failed or permission block | No |
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
- Notion space rate limit: other apps spend your write-back budget
Notion also limits a whole workspace across connections. A write-back worker under its own limit can still get 429 when other apps use the shared budget.
- Pinterest catalog image_link: 1000x1500 minimum, video_link 2 GB
Pinterest's catalog needs image_link at 1000x1500 or more; each additional_image_link becomes its own Pin and video_link takes MP4, MOV or M4V up to 2 GB.
- Portkey MCP gateway: per-user tool allowlists for Sume write tools
Portkey's MCP gateway can enable or disable tools per user and log every call. Use it to keep Sume's paid tools from most users, on top of Sume's gates.
- PrestaShop combination images: one AI image per color
In PrestaShop you upload every image on the product, then tick which ones belong to each combination. Make one image per color from a packshot with Sume.
Written by Sume