adverse_action.completed

The adverse-action flow finished

Emitted when the final (or post-adverse) notice has been delivered. The notice PDF is listed by GET /executions/{workflow_execution_id}/notice_artifacts.

Payload

id string (uuid) required
event string required One of adverse_action.completed
created_at string (date-time) required
data object required
- workflow_execution_id integer required
- workflow_id integer required
- node_id string required
- external_reference string
- flow string required
- notice_stage string required One of post_adverse final
- sent_to string
- delivery_channels array of string
- completed_at string (date-time)
- status string required One of completed

How to handle it

Answer 2xx as soon as the delivery is stored and do the real work on a queue. Any other response, a connection error or a timeout (5 s connect, 10 s read) counts as a failure: Cascades retries after 1m, 5m, 30m, 2h, 8h, 24h, then marks the delivery dead.
De-duplicate on the envelope's id — it is identical across retries and across every subscriber's copy of the same event — or on the X-Cascades-Delivery header, which names one delivery row.
Verify X-Cascades-Signature before you act on the body (next section).
Treat data as a pointer, not the record: read data.workflow_execution_id and call GET /executions/{id} for the current status, the decision and — with executions:read:full — the step_outputs.
This event carries no execution_mode. If your handler must tell test runs from live ones, join on workflow_execution_id and read input_context.execution_mode from the execution.

Verify before you trust it

Compute HMAC-SHA256(signing_secret, "<t>.<raw body>") and compare it in constant time with the v1 (or, during rotation, v0) value in X-Cascades-Signature. Samples are in the right-hand rail and in the verify webhooks guide.

Deliveries retry on any non-2xx response, so handle the same X-Cascades-Delivery id more than once safely. See all webhook events.