Replicate webhook URL custom id vs Sume job_id as the key

Replicate's tip is to add query params to the webhook URL, such as https://example.com/replicate-webhook?customId=123, to carry an internal id. With Sume, the body of each delivery already has request_id and job_id, and the docs say receivers must treat job_id as the idempotency key.

Replicate's example is from its webhook setup page; Sume's behavior is from Webhooks, read 2026-10-01.

How do I tie a Sume callback to my own record?

Store your record id next to the job_id when you submit, then look the record up from the job_id in the delivery body. The payload shown in the docs includes event (job.completed, job.failed or job.canceled), request_id, job_id and status.

Why not rely on the URL alone?

Redeliver re-POSTs the job's real terminal event with a fresh timestamp and signature, on the same URL. The docs say it does not change the destination URL: a new URL is a new job. So a per-job URL is fixed at submit time, and the same job can arrive more than once. Keying on job_id makes the second delivery a no-op.

What does a deduplicating receiver look like?

Verify the signature first (see debug Sume webhook delivery), then insert the job_id once.

const seen = new Set<string>(); // use a database unique key in production

export function handle(body: { event: string; job_id: string }) {
  if (seen.has(body.job_id)) return { duplicate: true };
  seen.add(body.job_id);
  // load your record by job_id, then act on body.event
  return { duplicate: false };
}

Should the receiver also poll?

It can. Reading GET /v1/jobs/{job_id}/status is a read, so it is safe to repeat, and it reports the job's current status.