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.retry_scheduled

A post-adverse notice delivery failed and a retry was scheduled

Employment (two-step) flow only. The post-adverse notice could not be delivered; Cascades scheduled another attempt at retry_at with exponential backoff. adverse_action.failed follows if the retry budget runs out.

Payload

  • id string (uuid) required
  • event string required One of adverse_action.retry_scheduled
  • 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 One of employment
    • notice_stage string required One of post_adverse
    • error string required
    • attempt integer required The attempt that just failed (1-based).
    • next_attempt integer required
    • retry_at string (date-time) required
    • wait_id integer Id of the internal wait record backing the retry.

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?