Gemini static vs dynamic webhooks: Sume sets one URL per job

Gemini offers two webhook styles: static webhooks registered once for a project, and dynamic webhooks attached to a single request through uris and user_metadata. Sume's docs describe only the second shape. You pass webhook_url on each submit call, and that URL belongs to that job.

Gemini details are from its Webhooks page (last updated 2026-09-23); Sume details are from Webhooks and Jobs and results, read 2026-10-01.

What are Gemini's static and dynamic webhooks?

The Gemini page describes dynamic webhooks as binding an endpoint to a specific job, aimed at agent-orchestration queues, with a request body that carries "uris": ["https://my-api.com/gemini-webhook-dynamic"] and a user_metadata object such as {"job_group": "nightly-eval", "priority": "high"}. Static webhooks are the project-level kind, verified with a stored static signing secret.

How does Sume register a callback?

Send mode: "webhook" with webhook_url on the submit request. The URL must be public HTTPS; localhost, private-network and non-HTTPS URLs are rejected. If you send webhook_url (or its alias callback_url) without a mode, you get webhook mode anyway.

Can I change the URL of a job that already exists?

No. Redeliver re-sends a job's real terminal event with a fresh timestamp and signature, but it does not change the destination: a new URL is a new job. Receivers should treat job_id as the idempotency key.

If an endpoint was down, use redeliver on the existing job rather than submitting again; see the redeliver workflow.

What should I do if I want one shared receiver?

Point every submit at the same receiver URL and route on the payload's event and job_id. Because the signing secret is derived per workspace, one verifier covers all of those jobs. Keep status_url polling as a backup for deliveries that never arrive, as the docs advise.