Reference

Payload fields

Use these fields to create readable receipts for workflow runs, scripts, cron jobs, internal tools, and AI-assisted automations.

JSON reference

Write for the person reading the receipt

Send summaries by default. A good receipt explains what happened without storing full customer messages, private files, secrets, API keys, or raw model payloads.

Quick example

This is a compact create-run payload for POST https://automationreceipts.com/api/v1/runs. For a full request example, start with the quickstart.

Create-run payload

{
  "automation_name": "Support Reply Drafter",
  "run_uid": "support-demo-20260517-1042",
  "source_type": "n8n",
  "status": "needs_review",
  "risk_level": "medium",
  "input_summary": "Customer asked about refund options.",
  "output_summary": "Workflow drafted a reply for review.",
  "approval_required": true,
  "approval_status": "pending",
  "callback_url": "https://example.com/review-result",
  "final_action": "Draft created but not sent."
}

Required fields

Field	Type	Description	Example
`automation_name`	string	Name of the workflow, job, or script. If it does not exist yet, the app creates it.	`Support Reply Drafter`
`run_uid`	string	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`	string	Send at least one summary so the receipt has something useful to explain.	`Customer asked about refund options.`

Optional run fields

Optional fields make the receipt easier to scan, filter, and review. Omit fields that do not apply to your workflow.

Field	Type	Description
`source_type`	string	Where the run came from. Defaults to `custom`.
`trigger_type`	string	A short label for what started the run, such as `new_support_email` or `scheduled_cron`.
`status`	string	Current run state. Defaults to `completed`.
`risk_level`	string	How risky the automation output is. Defaults to `medium`.
`model_used`	string	Model name, if useful for the receipt or debugging.
`tools_used`	string	Tools, APIs, models, or data sources used during the run.
`approval_required`	boolean	Use `true` when the output should wait for a recorded review outcome.
`approval_status`	string	Recorded review state. Defaults to `pending` when review is requested, otherwise `not_required`.
`approved_by_name`	string	Name of the reviewer, if it was already reviewed before logging.
`callback_url`	string	Optional URL that accepts a POST request after a human records a review action in Automation Receipts.
`final_action`	string	What happened next, such as draft held, email sent, ticket updated, or no action taken.
`error_summary`	string	Short explanation when the run failed.
`started_at`	datetime	When the run started. Any parseable date-time string is accepted.
`completed_at`	datetime	When the run completed. Any parseable date-time string is accepted.
`events`	array	Up to 50 timeline entries to show what happened during the run. Extra items in the create-run `events` array are ignored.

Send booleans as real JSON booleans

Send false as false, not "false". The string "false" may be treated as truthy by the API and can make approval look required.

Review result callbacks

Add callback_url only when the workflow that created the receipt should receive a review result later. When a person records a review action in Automation Receipts, the review is saved first. Automation Receipts then POSTs a small review result payload to the callback URL.

Callback payload

{
  "source": "automation_receipts",
  "run_uid": "support-demo-20260517-1042",
  "automation_name": "Support Reply Drafter",
  "review_status": "approved",
  "review_note": "Looks good.",
  "reviewed_at": "2026-05-27T10:30:00+12:00",
  "receipt_url": "https://automationreceipts.com/runs/123"
}

Callbacks are optional

The callback payload does not include input summaries, output summaries, API keys, user email, or the full receipt by default. If callback delivery fails, the saved review is not undone; the receipt records the callback status for follow-up.

Events

Events build the receipt timeline. Send them in the events array when creating a run, or append one later to /api/v1/runs/{run_uid}/events. The append-event URL uses run_uid, not numeric run_id.

Event payload

{
  "event_type": "action_taken",
  "event_label": "Reply sent",
  "event_summary": "The approved reply was sent to the customer.",
  "occurred_at": "2026-05-17T10:45:00+12:00"
}

Field	Type	Description
`event_type`	string	Timeline category. Defaults to `note`. Unknown values are recorded as `note`.
`event_label`	string	Short human-readable label. If omitted, the app derives one from `event_type`.
`event_summary`	string	One or two sentences about what happened.
`event_payload_json`	object	Optional structured details. Keep this small and avoid private payloads.
`occurred_at`	datetime	When the event happened. Any parseable date-time string is accepted.

Common values

Run status

pending, needs_review, approved, rejected, completed, failed, cancelled

Risk level

low, medium, high, unknown

Approval status

not_required, pending, approved, rejected, needs_changes

Source type

n8n, make, ifttt, stackai, zapier, custom_script, manual, other, custom

Field guidance

Unique run IDs

Use a workflow execution ID, timestamp, UUID, or another dynamic value for run_uid. Reusing a run_uid in the same workspace returns a duplicate response.

Approval is optional

Automation Receipts can record a review outcome, but approval may happen in the app, your workflow tool, chat, email, or not be required at all.

Readable summaries

Use input_summary, output_summary, and final_action to explain what happened without dumping unnecessary private data.

Event types

Use documented event types for clearer timelines. Missing labels can be generated, and unknown event types are recorded as note.

Allowed event types

trigger_received model_called tool_called data_accessed output_generated approval_requested approved rejected action_taken callback_delivered callback_failed failed note

Request limits and responses

Request bodies over 131072 bytes are rejected. When creating a run, the events array is capped to 50 items.

Status	Meaning	What to check
`400`	Valid JSON object required.	Send a JSON object body with valid syntax.
`401`	Missing, invalid, or revoked bearer token.	Use `Authorization: Bearer aar_live_...` with the full active API key.
`404`	Run not found when appending events.	Use the original `run_uid`, not numeric `run_id`.
`409`	Duplicate `run_uid`.	Generate a new unique `run_uid` for each run in the workspace.
`413`	Payload too large.	Keep the JSON request body at or below `131072` bytes.
`422`	Validation error or missing fields.	Check required fields and allowed values.

Next steps

Quickstart

Create a first receipt with one HTTP request and an example JSON payload.

Recipe library

See how these fields fit into practical workflow receipts.

Custom script

Send receipt payloads from PHP, PowerShell, cron jobs, and internal tools.