Outcome States

Delivery vs Outcome

CueAPI tracks two distinct things for every execution:

• Delivery status: Did the webhook get delivered? Did the worker claim the job? (pending, delivering, success, failed, missed)
• Outcome state: Did the business action actually happen? (reported_success, verified_success, verification_failed, unknown)

A webhook can be delivered successfully (HTTP 200) but the business action might fail. CueAPI tracks both.

Outcome States

Backward Compatibility

The outcome_success boolean field is preserved permanently. It exists alongside outcome_state for backward compatibility. Both are always present in API responses.

Verification Policies

Configure per-cue verification via the verification field on cue creation:

{
  "verification": {
    "mode": "require_external_id"
  }
}

Modes:

• none (default): any outcome accepted, state is reported_success
• require_external_id: outcome must include external_id evidence, otherwise verification_failed
• require_result_url: outcome must include result_url evidence
• require_artifacts: outcome must include artifacts evidence
• manual: outcome always set to verification_pending until manually verified via POST /v1/executions/{id}/verify

Transport compatibility

Worker-transport cues can now report evidence via CUEAPI_OUTCOME_FILE: a per-run temp file the handler may write JSON to before exiting. Every verification mode is supported on both transports:

On webhook transport, handlers attach evidence in the body of POST /v1/executions/{id}/outcome.

On worker transport, handlers write evidence fields to the file whose path is exposed as $CUEAPI_OUTCOME_FILE; the worker daemon reads the file, merges the evidence into its auto-report, and enforces a strict conflict-resolution ruleset for success. Schema, examples, and conflict rules are documented in the Worker Outcome File reference.

Note on historical state: versions of CueAPI before this change rejected cue create and patch requests that paired worker transport with an evidence-requiring verification mode, returning 400 unsupported_verification_for_transport. That rejection will be lifted once this release ships in a follow-up PR. Until then, the server still rejects those combinations on API surfaces it sees. cueapi-worker ≥ 0.3.0 is required for the worker side to actually satisfy the verification check.