Cascades Docs
Sign in to run requests with your own sandbox key. Sign in
View as Markdown Open in Claude Open in ChatGPT Add MCP server OpenAPI JSON OpenAPI YAML

adverse_action.failed

A notice could not be delivered

Emitted when sending a notice raised an error. For the post-adverse stage this fires only after the retry budget is exhausted (see adverse_action.retry_scheduled for the intermediate attempts); the execution then fails.

Payload

  • id string (uuid) required
  • event string required One of adverse_action.failed
  • 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 pre_adverse post_adverse final
    • error string required Human-readable delivery error.
    • failed_at string (date-time)
    • attempt integer `post_adverse` only: the attempt number that exhausted the retry budget.
    • status string required One of failed

How to handle it

  1. 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.
  2. 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.
  3. Verify X-Cascades-Signature before you act on the body (next section).
  4. 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.
  5. 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.

Was this page helpful?