Higgsfield webhook retries: two hours vs Sume's ten attempts

Higgsfield retries network failures and 5xx responses for up to two hours and treats any 4xx as permanent. Your endpoint has ten seconds to answer. Sume retries a failed delivery up to 10 times in total, with a fixed delay of 30 seconds by default and a 10-second timeout per attempt, and you can redeliver by hand after the automatic attempts run out.

Retry rules compared

The retry windows are different shapes. Higgsfield's is long and time-based. Sume's is short and count-based: with the default spacing, ten attempts cover roughly four and a half minutes between the first and the last. If your receiver can be down for longer than that, plan for the redeliver call and for polling.

Make the handler idempotent

Both providers say the same thing about duplicates: they can happen, so your handler must be idempotent. Record the event durably first, then return a 2xx. Higgsfield's page says to acknowledge valid duplicates with 2xx and reject envelopes you do not recognise. On Sume, key your table on job_id.

When the receiver was down too long

Sume's POST /v1/jobs/{job_id}/webhook/redeliver (needs jobs:write) re-sends the job's real terminal event with a fresh timestamp and signature. It does not use up one of the automatic ten attempts, and it does not change the destination URL. Higgsfield's webhook page describes no manual replay, so for a long outage you would read request_id status over the API instead.

The two answer one question the same way in the end. A webhook is a speed-up, and the status endpoint is the source of truth. Keep polling available for the events that never arrive.

Checklist

Four habits cover both APIs.

• Return 2xx fast and do the work after.
• Deduplicate on the job or request id plus the terminal status.
• On Sume, expect a retry after any non-2xx, including a 4xx you meant as final.
• Keep a slow polling sweep for jobs with no event.