Two-receipt method

Monitor the outcome, not just the run.

Automation Assurance is deliberately platform-agnostic. A start receipt opens the expectation; a completion receipt closes it only after the promised result exists.

1. Create an opaque run ID

Generate a unique ID at the workflow trigger. It must not contain a customer name, email, order number or other business payload.

2. Send the start receipt

POST /api/v1/receipts/start
Authorization: Bearer <workflow-token>
Idempotency-Key: <run-id>-start

{"workflowKey":"wf_lead_01","runId":"run_8f22","occurredAt":"2026-07-23T10:03:27Z"}

3. Confirm the real outcome

Place the completion request after the downstream record, notification or business state has been verified—not merely after the previous automation step returned 200.

POST /api/v1/receipts/complete
Authorization: Bearer <workflow-token>
Idempotency-Key: <run-id>-complete

{"workflowKey":"wf_lead_01","runId":"run_8f22","occurredAt":"2026-07-23T10:03:39Z","outcome":"succeeded"}

4. Review incidents and assurance

Each workflow has its own expected duration and grace period. Missing, late, failed and duplicate outcomes are recorded. Late completion resolves the alert without deleting its history.

Metadata boundary: unknown request fields are rejected. Do not send payloads, personal information, credentials or business records.