GitHub wants a 2XX in 10 seconds, Sume times out at 10: dedupe both

Both GitHub and Sume expect your endpoint to answer within 10 seconds, so the same handler discipline works for each: verify, store, return 2xx, process later. The dedupe key differs. GitHub keeps the X-GitHub-Delivery header constant when a delivery is redelivered; Sume's documented key is the job_id in the body.

The table puts the two side by side. If your service receives both, give them different routes and do not share a dedupe table keyspace.

Side by side

What redelivery looks like

With GitHub, the repeated delivery carries the same X-GitHub-Delivery value, so storing that value is enough to skip a repeat. With Sume, a redeliver call sends the real terminal event for that job with a fresh timestamp and signature, so the timestamp and signature change but job_id does not. Do not dedupe on the signature or timestamp.

One handler shape for both

• Read the raw body before parsing, keep it for signature checks.
• Insert the dedupe key into a table with a unique constraint. If it already exists, return 2xx and stop.
• Put the real work on a queue, then return 2xx. Do not call other APIs from inside the request.
• Remember that Sume's redeliver does not use one of the 10 automatic attempts, so a job can legitimately arrive again days later.

When 10 seconds is not enough

Treat a slow handler as a failed delivery for both services. For Sume, ten refused attempts still leave the job complete, so fall back to GET /v1/jobs/{id}/status and the result endpoint. Read the Sume webhooks docs for the fields.