Add one HTTP request to your AI workflow and get a readable receipt.
Reference
Every field the run API accepts, in plain language.
Send summaries by default. A good receipt explains what happened without storing full customer messages, private files, secrets, API keys, or raw model payloads.
Start with sample data before connecting real customer data. Do not paste API keys into screenshots, chat, public docs, or shared examples.
| Field | Plain meaning | Example |
|---|---|---|
automation_name |
Name of the automation that ran. If it does not exist yet, the app creates it. | Support Reply Drafter |
run_uid |
Your unique ID for this run. The same workspace cannot reuse it, so use a dynamic workflow value. | n8n-{{$execution.id}} |
input_summary or output_summary |
Send at least one summary so the receipt has something useful to explain. | Customer asked about refund options. |
| Field | Required | Plain meaning |
|---|---|---|
automation_name | Yes | Name of the workflow, job, or script. |
run_uid | Yes | A unique ID from your platform or script. |
source_type | No | Where the run came from. Defaults to custom. |
trigger_type | No | A short label for what started the run, such as new_support_email or scheduled_cron. |
status | No | Current run state. Defaults to completed. |
risk_level | No | How risky the automation output is. Defaults to medium. |
input_summary | One summary required | Short summary of the trigger or input. |
output_summary | One summary required | Short summary of what the AI produced. |
model_used | No | Model name, if useful for audit or debugging. |
tools_used | No | Tools, APIs, or data sources the AI used. |
approval_required | No | Boolean. Use true when the output should wait for a recorded review outcome. Send a real JSON boolean, not the string "true" or "false". |
approval_status | No | Recorded review state. Defaults to pending when review is requested, otherwise not_required. |
approved_by_name | No | Name of the reviewer, if it was already reviewed before logging. |
final_action | No | What happened next, such as draft held, email sent, ticket updated, or no action taken. |
error_summary | No | Short explanation when the run failed. |
started_at | No | When the run started. Any parseable date-time string is accepted. |
completed_at | No | When the run completed. Any parseable date-time string is accepted. |
events | No | Up to 50 timeline entries to show what happened during the run. |
statuspending, needs_review, approved, rejected, completed, failed, cancelledrisk_levellow, medium, high, unknownapproval_statusnot_required, pending, approved, rejected, needs_changessource_typen8n, make, zapier, custom_script, manual, other, customUse needs_review with approval_required: true and approval_status: pending when AI drafts something that should wait for review.
Use completed with approval_required: false and approval_status: not_required for runs that do not need a recorded review outcome.
Automation Receipts can record the review outcome, but approval can happen in Automation Receipts, your workflow tool, chat, email, or somewhere else.
Use failed and include error_summary when the automation could not finish.
Events build the receipt timeline. You can send them in the events array when creating a run, or append one later to /api/v1/runs/{run_uid}/events.
| Field | Required | Plain meaning |
|---|---|---|
event_type | No | Timeline category. Defaults to note. |
event_label | No | Short human-readable label. If omitted, the app derives one from event_type. |
event_summary | No | One or two sentences about what happened. |
event_payload_json | No | Optional structured details. Keep this small and avoid private payloads. |
occurred_at | No | When the event happened. Any parseable date-time string is accepted. |
event_type valuestrigger_received, model_called, tool_called, data_accessed, output_generated, approval_requested, approved, rejected, action_taken, failed, note