Recipe
Support Reply Drafter
Record a workflow that receives a support message, prepares a reply draft, logs a readable receipt, and records what happened next.
What this recipe records
Automation Receipts records the workflow run. It is not the workflow builder, and it does not need to be the approval gate. Review may happen in Automation Receipts, n8n, Slack, email, another tool, or not be required at all.
When to use this recipe
Support inboxes
A message arrives from email, a ticketing system, a form, chat, or an internal support queue.
Draft replies
A workflow prepares a suggested response, summary, next step, or internal note for someone to review.
Human review
Use this when a person may need to approve, reject, revise, or simply read the generated draft before action is taken.
Final action logging
Keep a receipt trail for whether the reply was sent, held, edited, escalated, or left waiting.
Workflow shape
Message received
A support message starts the workflow.
Draft prepared
A model, template, or script prepares a suggested reply.
Receipt created
The workflow sends one JSON request to Automation Receipts.
Review recorded
Optional review status is stored on the receipt.
Action logged
A later event records what happened next.
Example run payload
Send this payload to POST https://automationreceipts.com/api/v1/runs. Keep the summaries readable and avoid sending full private customer messages unless you have a clear reason to store them.
Create support reply receipt
{
"automation_name": "Support Reply Drafter",
"run_uid": "support-reply-20260517-1042",
"source_type": "custom",
"trigger_type": "support_message_received",
"status": "needs_review",
"risk_level": "medium",
"input_summary": "Customer asked about a possible duplicate charge and how to get it reviewed.",
"output_summary": "A reply draft was prepared explaining that the team can review duplicate charges and asking for account confirmation.",
"model_used": "reply-drafting-workflow",
"tools_used": "Support inbox, customer account lookup, reply draft step",
"approval_required": true,
"approval_status": "pending",
"final_action": "Draft created but not sent.",
"events": [
{
"event_type": "trigger_received",
"event_label": "Support message received",
"event_summary": "A customer support message started the reply-drafting workflow."
},
{
"event_type": "data_accessed",
"event_label": "Account context checked",
"event_summary": "The workflow checked limited account context needed to understand the duplicate-charge question."
},
{
"event_type": "output_generated",
"event_label": "Reply draft prepared",
"event_summary": "The workflow prepared a reply draft for review."
},
{
"event_type": "approval_requested",
"event_label": "Review requested",
"event_summary": "The draft is waiting for a review outcome before any customer reply is sent."
}
]
}Use a unique run ID
Replace the example run_uid with a workflow execution ID, timestamp, UUID, or another dynamic value. Reusing the same run_uid in a workspace returns a duplicate response.
Example events
Events build the timeline on the receipt. Send them in the create-run payload, or append later with /api/v1/runs/{run_uid}/events.
| Event type | Label | What it records |
|---|---|---|
trigger_received | Support message received | The workflow started from a customer or support message. |
data_accessed | Account context checked | The workflow used limited context needed for the draft. |
model_called or output_generated | Reply draft prepared | A model, template, or script prepared the reply text or internal note. |
approval_requested | Review requested | The draft is waiting for a person or another system to review it. |
approved, rejected, or note | Review outcome recorded | The review result was recorded, including needs-changes notes when useful. |
action_taken | Reply sent or held | The workflow logged the final action, such as sent, edited, escalated, or held. |
Append the final action
If the final action happens after the receipt is created, append a timeline event using the original run_uid, not the numeric run_id.
Append event request
curl -X POST "https://automationreceipts.com/api/v1/runs/support-reply-20260517-1042/events" \
-H "Authorization: Bearer aar_live_REPLACE_ME" \
-H "Content-Type: application/json" \
-d '{
"event_type": "action_taken",
"event_label": "Reply sent",
"event_summary": "The reviewed support reply was sent to the customer.",
"occurred_at": "2026-05-17T10:48:00+12:00"
}'n8n notes
HTTP Request node
- Method
POST- URL
https://automationreceipts.com/api/v1/runs- Body type
- JSON
- Headers
Authorization: Bearer aar_live_...
Static and dynamic fields
Static values are fine for the first test. Use n8n expressions for fields that must change each run, especially run_uid.
support-reply-{{$execution.id}} is a good pattern when the execution ID is available.
For the first n8n test, use Manual Trigger, Edit Fields, and one HTTP Request node before connecting live inboxes, customer data, or actions that send messages. The n8n guide includes a starter workflow JSON you can import or copy from.
Custom script notes
Same API payload
The same JSON payload works from curl, PHP, Python, PowerShell, cron jobs, backend scripts, and internal tools.
Useful beyond support
Use the pattern for any workflow that prepares a message, note, summary, customer update, or internal action for review.
Review and approval notes
Approval is optional
Set approval_required to true when the receipt should show a pending review. If review happens elsewhere, Automation Receipts can still record the outcome with approval_status, reviewer fields, and timeline events.
| Workflow state | Suggested fields |
|---|---|
| No review needed | approval_required: false, approval_status: "not_required" |
| Waiting for review | status: "needs_review", approval_required: true, approval_status: "pending" |
| Approved elsewhere | approval_status: "approved", optional approved_by_name, and an approved event |
| Needs changes | approval_status: "needs_changes" and a short note event explaining the requested edit |
| Rejected | approval_status: "rejected" and final_action such as Draft rejected; no reply sent. |
Privacy and data guidance
Summaries first
Send short summaries instead of raw private email content, full ticket threads, documents, or model payloads.
Limit customer data
Only include names, emails, account details, or identifiers when they are genuinely useful for the receipt reader.
Keep it readable
Write input_summary, output_summary, event summaries, and final_action for humans reading the receipt later.
Common issues
| Problem | What it usually means | Fix |
|---|---|---|
400 bad request | The body is not a valid JSON object. | Use JSON body mode and check commas, quotes, brackets, and dynamic expressions. |
401 unauthorized | The bearer token is missing, wrong, or revoked. | Use Authorization: Bearer aar_live_... with the full active API key. |
409 duplicate run_uid | A receipt already exists with that run ID in the workspace. | Use a dynamic value such as support-reply-{{$execution.id}} or a timestamp. |
413 payload too large | The JSON body is over the request limit. | Send concise summaries instead of raw emails, full ticket threads, documents, or model payloads. |
422 validation error | A required field is missing or a value is not allowed. | Check automation_name, run_uid, and at least one summary field. Also check values such as source_type, status, and approval_status. |
| Boolean values sent as strings | approval_required was sent as "true" or "false". | Send true or false without quotes. |