Skip to content

on_exit Hooks

The on_exit field in a recipe definition specifies a step that runs after the main pipeline completes — regardless of success or failure.

How it works

  1. All main recipe steps run to completion (success, failure, or skip)
  2. Ordo triggers the on_exit step
  3. The on_exit step runs and reports back

The on_exit step is not part of the main DAG. It's guaranteed to run once the pipeline settles into a terminal state.

CALL_WEBHOOK pattern

The standard use is to send a webhook after processing:

json
"on_exit": {
  "id": "call_webhook",
  "type": "CALL_WEBHOOK",
  "inputs": { "waits_for": "step:dataset_info.metadata" },
  "param_keys": ["webhook_url"]
}

The waits_for input is an execution barrier — the step waits for the referenced artifact to exist before firing. Wiring it to step:dataset_info.metadata ensures the metadata is available when the webhook payload is sent.

What the webhook receives

Before sending the webhook, CALL_WEBHOOK queries GET /ordo/jobs/{job_id} and sends the full response as the POST body:

json
{
  "job": {
    "id": 4,
    "status": "success",
    "created_at": "...",
    "started_at": "...",
    "finished_at": "...",
    "params": { ... }
  },
  "progress": { "percentage": 1, "completed_steps": 3, "total_steps": 3 },
  "duration_ms": 145200,
  "timeline": [ ... ],
  "steps": [ ... ],
  "artifacts": [ ... ],
  "outputs": [ ... ]
}

This gives the receiving system full visibility into what was processed, what artifacts were produced, and whether any steps failed.

Failure tolerance

Webhook delivery failures (network errors, non-2xx responses) are caught and ignored by the CALL_WEBHOOK executor. A webhook failure does not cause the job to fail.

Providing the webhook URL

Add webhook_url to the job's params under the on_exit step's ID:

json
"params": {
  "call_webhook": {
    "webhook_url": "https://myapp.example.com/hooks/processing-done"
  }
}

If your on_exit step has id: "notify" then the param key would be "notify".