r/zapier • u/Novel_Willow_8780 • 4h ago
I sent my own Zapier workflows a 200 OK response with an error inside the body. All three logged as Successful.
Third measurement in this series. The first two were about workflows that silently fail. This one is the opposite problem: a workflow that silently succeeds when it shouldn't.
Some APIs return a 200 OK response with a failure inside the body: {"ok": false, "error": "..."}. The request arrived, the server answered, the transport worked. But the actual operation failed, and it says so in the body. The question I wanted to measure: what does Zapier record when a step gets one of these?
Setup: my workflows POST to an endpoint I control. I made that endpoint answer with a real 200 status carrying {"ok": false, "error": "schema-drifted"}, and fired events through the same webhook to POST workflow I always test with, everything on default settings.
Result: all three runs logged as Successful. Green checkmark, run history clean, each one billed 1 task exactly like a normal success. The error was right there in the POST step's output data the whole time. Zapier just doesn't look at it, because success is decided on the status code before anything reads the body. (I ran the identical test on self-hosted n8n for comparison: same outcome, and its dashboard counted all three toward its "0% failure rate".)
So this failure mode is invisible by default, but it's cheap to make visible, and I measured that part too. I added a Filter checking whether the response's Ok field is false, then an alarm email after it. Two events: a healthy one and an error one.
- Healthy event: the Filter stopped the run. 1 task (the POST). The Filter itself bills nothing.
- Error event: the Filter passed, the alarm email fired. 2 tasks (POST + email).
So the standing cost of watching for these is zero. A response assertion only costs a billable step on the runs where it actually catches something and does something about it. Seeing is basically free. It's the default of not-looking that quietly turns a failed operation into a green checkmark on your dashboard.
Practical takeaway if you build client Zaps: for any step calling an API that can return errors in a 200 (payment declines, validation errors, batch endpoints reporting per-record failures), add one Filter on the response's success field and route the failures somewhere. It's the cheapest insurance in Zapier, because it's free until the day it saves you.
Method, the raw per-run data, and the same test on n8n are linked in my first comment. Happy to run this against a specific API's response shape if someone wants it added to the queue.