Mock APIs for Zapier — test Webhooks by Zapier, error handlers, Autoreplay, and Catch Hook triggers

A Zapier Zap has the same two hard-to-test halves as any integration. Outbound: Webhooks by Zapier steps (a premium app, available on paid plans) POSTing to APIs you can't make fail on demand — so your error handler paths and Autoreplay settings ship unexercised. Inbound: Catch Hook triggers that need realistic deliveries — ideally with real signature headers — to prove the Zap parses them.

Zapier's own getting-started guide for webhooks tells you to inspect payloads with RequestBin — but requestbin.com now 301-redirects to Pipedream, and creating a bin there requires signup first. This guide is the workflow that doc describes, against a live stateful mock that also fails exactly when you tell it to. Every curl below was verified against production before publishing.

1. A stand-in API for Webhooks by Zapier steps

The public demo project is a seeded e-commerce API. In a Webhooks by Zapier action (GET, POST, or Custom Request), set the URL to:

https://mockbird.mockbird.workers.dev/m/demo/products?limit=2

Test the step — two product records come back and map into later steps like any real API response. Writes work too: POST /m/demo/products creates a record a later GET step can fetch back. Standard REST conventions (_page/_limit/sortBy/filters), so paginated pulls are testable. Want your own schema instead of ours? One curl or one click, below.

2. See exactly what your Zap sends — the RequestBin job

When a Zap POSTs to a partner API and the partner says "malformed payload", you want the request verbatim. That's exactly what Zapier's docs used RequestBin for. Point the webhook step at a bin instead:

curl -s -X POST https://mockbird.mockbird.workers.dev/m/demo/hooks/order-created \
  -H 'content-type: application/json' -d '{"orderId":123,"total":49.9}'
# → {"ok":true,"caught":"POST /hooks/order-created","body":{...},"receivedAt":"…"}

The demo's catch-all route echoes what it caught, and every hit — method, path, headers, body — lands in the public demo request inspector. Line breaks in your line-item field, the content-type Zapier actually sent, the empty field you thought was mapped — it's all there. On your own project, an empty project plus one ANY /* custom route is a private bin with a per-project inspector: no signup, no 7-day expiry.

3. Run your error handler path on purpose

Zapier's custom error handling splits a step into Success and Error paths — and the Error path usually gets tested by hoping something breaks. A webhook step that receives a 4xx/5xx response errors, so make it break on demand:

https://mockbird.mockbird.workers.dev/m/demo/products?mock_status=500

That request fails the step and routes the run down your Error path — Slack alert, fallback write, whatever it does. Remove the param and the same step returns 200. One URL parameter is the whole toggle. mock_status takes any code (try 404 vs 500 if your handler branches on them); combine with &mock_delay=2000 for slow-then-fail.

4. Drill Autoreplay with a deterministic recovery

Autoreplay (Professional plans and higher) retries a failed step up to 5 times on a delay schedule. The problem is proving it recovers: real APIs don't fail twice then succeed on cue. ?mock_seq does exactly that:

# 1st request → 500, 2nd → 500, 3rd and later → real 200 response
curl -s -o /dev/null -w '%{http_code}\n' \
  'https://mockbird.mockbird.workers.dev/m/demo/products?mock_seq=500,500,200&mock_seq_key=myzap'
# run it four times: 500 500 200 200

Point the webhook step at that URL and let the run fail: the first replay eats the second 500, the next one lands the 200, and the run flips from Errored to Success — Autoreplay demonstrably did its job. Every response carries x-mockbird-seq: pos/len so Zap history shows which attempt hit which step of the sequence. Use a distinct mock_seq_key per Zap so parallel tests don't share a counter, and &mock_seq_reset=1 to restart. Failed writes are not applied — a POST that draws a 500 inserts nothing, so a replayed step can't double-insert on our side.

5. Practice 429 handling before the real API rations you

# allow 3 requests per 60s per client, then 429 with Retry-After
'https://mockbird.mockbird.workers.dev/m/demo/products?mock_ratelimit=3&limit=1'
# 4 rapid requests → 200 200 200 429

A burst of trigger events (a spreadsheet import, a flash sale) will hammer whatever your Zap calls. Responses carry x-ratelimit-limit / x-ratelimit-remaining / x-ratelimit-reset, and the 429 includes Retry-After — rehearse whether your Zap should let Autoreplay absorb it (§4), route 429s down an Error path (§3), or add a Delay step upstream.

6. Slow upstreams

curl -s -o /dev/null -w '%{time_total}\n' \
  'https://mockbird.mockbird.workers.dev/m/demo/products/1?mock_delay=3000'
# 3.19s

Zapier gives each step 30 seconds; mock_delay goes up to 5,000 ms — enough to see how a sluggish upstream feels in Zap history and in multi-step runs, though honestly not enough to trip Zapier's 30-second timeout itself. mock_jitter adds a random component if you want latency that isn't suspiciously constant.

7. Fire realistic signed deliveries at a Catch Hook

Mockbird projects can send outbound webhooks on every record change — signed POSTs with x-mockbird-event, x-mockbird-delivery, and x-mockbird-signature: sha256=… (HMAC-SHA256) headers. That's a realistic stand-in for any signed-webhook provider. Aim it at your Zap's Catch Hook URL:

# point your project's webhook at the Catch Hook URL (returns the signing secret)
curl -s -X PUT https://mockbird.mockbird.workers.dev/api/projects/YOUR_ID/webhook \
  -H "x-admin-key: YOUR_ADMIN_KEY" -H "content-type: application/json" \
  -d '{"url":"https://hooks.zapier.com/hooks/catch/1234567/abcdef/"}'

# instant test delivery, no record edit needed:
curl -s -X POST https://mockbird.mockbird.workers.dev/api/projects/YOUR_ID/webhook/test \
  -H "x-admin-key: YOUR_ADMIN_KEY"

Click Test trigger in the Zap editor and the delivery appears as a sample request — with headers, if you use Catch Raw Hook, which is what you want for verifying the signature in a Code step with the returned secret. Then edit any record in the project and a real products.updated-style event arrives on its own — a live drip of realistic traffic for testing filters and paths. Delivery attempts (status, error, duration) are listed at GET …/webhook/deliveries. More recipes: sending test webhooks.

8. A target for the Retrieve Poll trigger

Webhooks by Zapier also has a Retrieve Poll trigger: Zapier polls a REST endpoint and triggers on new items (matched by id). It supports basic auth only — which makes an open mock project the easiest possible target while you build:

https://mockbird.mockbird.workers.dev/m/demo/orders?sortBy=id&order=desc&limit=10

Poll that, then POST a new order (from a curl, or from another Zap) and watch the trigger fire on the new id. Because writes persist, you control exactly when a "new item" appears — which is the entire difficulty of testing polling triggers against real apps.

9. Your own API instead of the shared demo

One curl (or one click), no signup:

curl -s -X POST https://mockbird.mockbird.workers.dev/api/projects \
  -H "content-type: application/json" \
  -d '{"preset":"ecommerce"}'
# → {"id":"abc123xyz9", "adminKey":"…", ...}

Presets: blog / ecommerce / saas — or define resources by hand, or import an OpenAPI spec, db.json, CSV, or HAR recording of the real API. Every simulation param above works on your project's URLs. Projects have a 10,000 requests/day cap — Zap testing barely dents it.

Where Zapier's built-ins are still the right tool

Fair's fair: Zapier's step tester with real sample data is the fastest way to build field mappings against the apps you actually use, and its Zap history with AI troubleshooting is genuinely good at explaining what went wrong after the fact. Use them. Reach for a hosted mock when the thing under test is the HTTP layer itself: what your Zap sends, how it behaves when the other side errors, rate-limits, crawls, or recovers — the runs you'd rather not rehearse against a production CRM. They compose: build the happy path on real apps, drill the failure paths on a mock.

Verification: all demo curls on this page (bin echo + inspector log, mock_status 500, seq 500→500→200→200, 200 200 200 429 rate-limit run, 3.19s delay, orders poll target) were run against production on 5 Sep 2026 before publishing. Zapier behavior — Webhooks by Zapier as a premium app on paid plans, the RequestBin recommendation in the official getting-started doc, requestbin.com's 301 to Pipedream's signup-walled product, error handler Success/Error paths, Autoreplay on Professional+ retrying up to 5 times, the 30-second step timeout, Retrieve Poll's basic-auth-only polling — is from Zapier's official help docs and our own checks, verified 5 Sep 2026. We don't run your Zaps; if a step here doesn't work, that's a bug: tell us.