Sume run webhook: two request_ids, which one to dedupe on

Use the top-level request_id of the webhook envelope. It equals run_id and stays the same across retries. The receipt inside payload has its own request_id, which is a correlation id for the call that produced the receipt, and you should ignore it for deduping.

Why there are two

The payload is the same receipt that GET /v1/{family}-runs/{run_id} returns in data. When you poll, its request_id is an HTTP req_... id. Inside a webhook, Sume sets it to the run id. If you wrote one parser for both transports, a second dedupe key hidden in the receipt is a trap: it differs by transport.

Ordering and outcome

Retries repeat the same request_id, so it cannot order deliveries. created_at is the time Sume built each delivery body, so use it for order. Branch on outcome, not just status: ok, degraded or error.

A canceled run sends no webhook, so your dedupe table will never see one.

A minimal rule

Insert the envelope request_id into a unique column before doing work. If the insert conflicts, return success and stop. Then process payload with the same code you use for polled receipts.