Notion 504 gateway_timeout: check the page before you retry

Do not retry a Notion 504 blindly. The Notion changelog says a 504 gateway_timeout "does not mean the write was undone", so the page may already hold your Sume video URL. Read the page first, write only if the URL is missing, and key the whole step on the Sume job_id.

Notion facts are from its changelog entry of September 24, 2026; Sume behavior is from Webhooks and Asset library, read 2026-09-30.

What changed in Notion's errors?

The changelog says updating a page's content as markdown and the notion-update-page MCP tool now return HTTP 504 gateway_timeout when a request runs past its deadline. Before, they returned HTTP 500 internal_server_error. It also says any 429 or 529 response that carries a Retry-After header now repeats the wait in the body as additional_data.retry_after.

Why does this matter for a video webhook?

When a Sume job finishes you get a job.completed webhook, and your receiver writes the result URL to a Notion page. If that write times out and you simply retry, a write that did land is applied twice. The Sume docs state that Sume sends terminal job events only and that receivers must treat job_id as the idempotency key.

Sume allows 10 seconds per attempt on its delivery, so the receiver should acknowledge fast and do the Notion write after responding, not inside the request.

Which URL should the page store?

Store the Sume artifact URL from the job result. The asset library page says integrations should store the Sume URL, not raw provider URLs. Writing the same value again after a timeout is harmless if you check first.

How do I write once after a 504?

Keep a record keyed by job_id. On a 504, read the page, and compare the property or block to the artifact URL. Write only when it is absent, and honor additional_data.retry_after on a 429 or 529. If delivery fails entirely, Sume can re-POST a job's real terminal event through POST /v1/jobs/{job_id}/webhook/redeliver, which your job_id check will absorb.