Stripe wants enabled_events trimmed; Sume sends only terminal events

Stripe's best practices say to configure each webhook endpoint to receive only the event types your integration needs, using enabled_events. Sume has no such list to trim. Its webhooks fire on terminal events only, and the URL is set on each request rather than registered once for your account.

Stripe's model: register once, then filter

On Stripe you create an event destination and choose the event types. Stripe warns that listening for extra events, or all events, puts undue strain on your server. It also allows up to 16 destinations per mode, so a team often splits endpoints by concern.

Sume's model: per call, terminal only

On Sume you pass a public HTTPS webhook_url on the request that starts the work. The events are job.completed, job.failed and job.canceled for jobs, and format.run.terminal, action.run.terminal and agent.run.terminal for runs. Every one is a terminal event. There are no progress events to subscribe to. For progress, poll status_url or read the events_url.

What changes in a handler

Because the URL is per request, you can send different jobs to different handlers without any registration step. You can also send many jobs to one URL and tell them apart by job_id, which is the idempotency key in any case.

• Route on event, then on status. status OK or ERROR tells you the branch, and outcome (ok, degraded, error) refines it for runs.
• Do not wait for a progress event. There will not be one.
• A canceled or skipped run sends nothing, so a handler that waits for a callback on a canceled run will wait forever. Cancel from your side and mark it yourself.
• Return 204 or 200 for an event name you do not know, so a new event type does not turn into retries.

Porting tip

If you are moving a multi-event Stripe handler to Sume, start from the families you actually call. A team that only submits jobs needs one route for the three job events. A team that runs Formats needs one for format.run.terminal and should look at both status and outcome, since a degraded run still reports status OK.

Document the contract in your own code: which events you expect, which you ignore, and what you do with an unknown name. That makes a later change, such as a new terminal event type, a one-line decision instead of an incident. Return a 2xx for ignored events so the sender does not retry them.