Direct answer
n8n Workflow Receipts
An n8n workflow runs while you sleep, and in the morning the execution log says it worked. The log lives on the same server, under the same admin, as the workflow it describes, and a client reading an export of it is trusting the operator completely. n8n workflow receipts are the outside record: run the load bearing calls of the workflow through Zambo, the verifiable work layer for AI, and each executed call files a verifiable receipt at the moment it runs. Anyone, including the client, checks a receipt free at zambo.dev/verify, no account on your n8n required. This page covers the honest starting point, where Zambo sits inside a workflow, proof of execution vs logs, and delivery of run records to clients and teams.
Updated October 20, 2026.
The honest starting point: n8n logs are the workflow word for itself
n8n is unusually transparent as automation goes: executions are listed, node outputs can be inspected, and errors surface honestly. None of that makes the log evidence for a second party. The execution history sits in your n8n database, on your infrastructure, exportable and editable by whoever administers the instance. When everything is fine, nobody cares. When a client says the leads never arrived, the sync silently dropped half the records, or the report was built on stale data, the log export you send is your system testifying for your system.
The structural gap is sharper for automation than for chat, because the whole selling point is that nobody watched. A freelancer sells an n8n build precisely so the client never has to look at it. Weeks later, the client needs to check a specific run, a specific record, a specific claim, and the only witness is the machine that did the work, operated by the person being questioned. Receipts close that gap the same way they close it for chat based work: file the executed steps outside the system, at run time, in a form the other party can verify without logging into anything of yours.
Where Zambo sits inside an n8n workflow
The pattern is one node change in thinking, not a rebuild. Inside the workflow, the calls that carry claims, the data pull the report depends on, the enrichment, the price or source check, the delivery step, are routed through Zambo instead of being called bare. Zambo exposes its endpoint at https://zambo.dev/mcp, one URL and no key, with 153 tools in total and 35 on the default surface, and n8n reaches it the way n8n reaches any service: from the workflow, at the step where the claim is made. Each call executes through Zambo and the saved result is filed with its verifiable receipt before the workflow moves on.
For builders, the n8n workflow receipt API pattern is exactly that: the workflow, your code, calls the endpoint for the steps that need a record, receipts return with the results, and the workflow stores or forwards the receipt links with its output. The client facing deliverable can then include the record by construction: the daily report carries its handover link, the lead batch lands with its receipts attached, the sync summary names its checks. The n8n workflow receipt tool, in other words, is not another dashboard. It is the endpoint the workflow already passes through, filing as it goes.
Coverage stays honest by design. Nodes that never route through Zambo, a local transform, a direct call you chose not to move, produce no receipt, and the run packet lists them as unchecked. That honesty is what lets a client trust the covered steps: the record claims exactly what it can prove and labels the rest, instead of wrapping the whole workflow in a blanket claim nobody should believe.
What an n8n workflow receipt proves
A receipt records the tool that was called, the input it received, the result that was saved, and the execution time. At zambo.dev/verify, anyone recomputes the saved result against the filed record. A pass confirms the output the workflow acted on is the output that came back at that run, unchanged since. A fail is public and specific. Strung across a run, the receipts answer the questions logs cannot settle for an outsider: this source was actually queried, this record set is what came back, this check ran before the send, at this time, returning this.
The n8n workflow work receipt, the form a client actually receives, is the handover built from the run: the goal of the workflow run, the routed steps in order, their outputs and receipts, and the open items, in one link. For a recurring automation, each scheduled delivery can carry its own link, so the client record accumulates run by run instead of living as a claim about the system in general. When a dispute names a date, the packet for that date is the conversation.
n8n workflow proof of execution vs logs
The vs logs argument for n8n is the strongest version on this hub, because n8n logs are good logs and it still is not close. A good log is complete, timestamped, and inspectable, by the operator. For the client, the agency buyer, or the teammate on another instance, the export is unverifiable: the store is yours, the export is yours, and a trimmed history looks exactly like a full one. Proof of execution moves the record outside the operator store at run time, into the open AER-1 format (IETF Internet-Draft draft-zambo-aer1-24), verified by recomputation at a public page neither party administers.
Practically: keep n8n execution logs for debugging, retention, and your own incident work. They are the right tool for the operator. File receipts for the steps a second party will judge, the deliveries, the data claims, the sends, and let each record type do the job it is built for. Teams that blur the two end up exporting logs in disputes and discovering, live, that an export convinces nobody who was already inclined to doubt.
n8n workflow receipts without screenshots
The screenshot version of automation proof is an execution list screenshot plus a node canvas screenshot, both meaningless to a client within a week. n8n workflow receipts without screenshots replace the pictures with run packets: links the client opens, steps they read in plain order, checks they run free at the verifier. An agency delivering automations to several clients sends the same packet shape with every run delivery, and clients learn the shape once. A freelancer handing over a workflow at the end of a build includes the recent run packets, so the client inherits evidence, not just a login.
Open source workflow builders get the public version of the same benefit. Publish the run packet with the workflow and any user can verify the routed steps of the reference run at the public verifier, because the format and the checker are open. The workflow reputation stops resting on the builder instance and starts resting on records strangers can test, which is where open source credibility has always come from.
Notes for your situation
The searches behind this page come in flavors. The record does not change; what changes is who checks it and why:
n8n workflow receipts for freelancers: deliver the build with recent run packets. The client sees the automation working on the record, checks steps free, and the handover acceptance closes the build in writing.
n8n workflow receipts for teams: the team reviews run packets in the incident or weekly thread: which steps executed, what came back, verified without anyone exporting logs from the production instance.
n8n workflow proof of execution for agencies: agencies running client automations attach the run packet to every delivery cycle, so proof is a habit of the system rather than a scramble during a dispute.
n8n workflow proof of execution for clients: clients get a link per delivery: the run goal, the routed steps, the outputs, the receipts, and an Accept or Flag decision that is filed on the record.
n8n workflow proof of execution for teams: operators keep logs for debugging and packets for accountability; the split ends the practice of pasting production exports into chat as evidence.
n8n workflow proof of execution open source: share the reference run packet with the workflow. Users verify the routed steps at the public verifier; the AER-1 draft and its test vectors are open to inspect.
n8n workflow receipt API and tool: the API is the endpoint the workflow already calls: route a step, get the result with its receipt, and let the workflow forward the links with its own output.
What it costs
Public handovers are free to send and free for the client to open. For $0.99, a Day Pass covers 24 hours of recorded work through the Zambo MCP at https://zambo.dev/mcp, 153 tools in total with 35 on the default surface. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402. Frame it against the problem on this page: one payment turns a day of AI work from a claim into a record that anyone can check, which is the difference between arguing about a job and closing it.
Honest limits
Three edges, stated plainly. First, a verifiable receipt proves the saved result was not changed after the fact; it never proves the work was correct, well judged, or worth what you charged. The client still judges whether the workflow logic was the right logic for their process. Second, the record only covers steps that ran through Zambo: work n8n did entirely on its own, outside the routed calls, has no receipt, and an honest packet lists that work as unchecked instead of pretending it is covered. Third, a receipt is a record, not a legal contract or a payment: pair it with your normal agreement and invoice, and let each document do its own job. AER-1, the receipt format underneath, is an IETF Internet-Draft (draft-zambo-aer1-24), not a finalized standard.
Frequently asked questions
What are n8n workflow receipts?
n8n workflow receipts are checkable records of the calls a workflow executed, filed when each call ran. n8n itself keeps execution logs on your instance, which are the workflow own account, held by the operator. Route the load bearing calls of a workflow through Zambo at https://zambo.dev/mcp and each executed call produces a verifiable receipt. Anyone can check a receipt free at https://zambo.dev/verify/ without access to your n8n, and a run receipts travel together in one handover link for the client.
Does n8n itself issue Zambo receipts?
No. n8n does not issue Zambo receipts. Zambo records the calls that run through the Zambo endpoint: when your workflow routes a step through Zambo, Zambo executes the call and files the saved result with a receipt. Nodes and direct calls that never touch the endpoint produce no Zambo record, and an honest run packet lists them as unchecked. Route the steps that carry claims, the data pulls, checks, and deliveries a client will judge, and the record covers exactly the work it should.
How are n8n workflow receipts different from n8n execution logs?
n8n execution logs live in your instance database, under your administration, and an export of them is the operator testifying for the operator. A client cannot test an export or tell a full history from a trimmed one. A Zambo receipt is filed outside your instance at run time, in the open AER-1 format, and anyone can recompute it free at https://zambo.dev/verify/ with no access to your server. Keep logs for your own debugging. Use receipts when a second party has to be convinced, which is what client delivery is.
How do I give a client proof an n8n run did the work?
Route the claim carrying calls of the workflow through Zambo, then send the client the handover link for the run: the goal, the routed steps in order, their outputs, the receipt on each, and any open items. The client opens it with no account and no access to your n8n, checks any receipt free at https://zambo.dev/verify/, and accepts the delivery or flags a specific step. Only the client can accept. For recurring automations, send the packet with each delivery so the record accumulates run by run.
How much do n8n workflow receipts cost?
Checking any receipt is free at https://zambo.dev/verify/, and public handovers are free to send and free to open. For $0.99, a Day Pass covers 24 hours of recorded work through the Zambo MCP at https://zambo.dev/mcp, which runs 153 tools in total with 35 on the default surface. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402.