Zapier Catch Hook URL is the same in test and live: test Sume safely
Zapier's Catch Hook URL does not change between test and live. Use Sume's webhook.test delivery to check the Zap before a real run sends a real result into it.

Zapier's help page says the Catch Hook URL is the same in test and live, so there is no separate test address to keep real traffic away from. For Sume, that means the safest first check is a test delivery: POST /v1/webhooks/test-deliveries sends a dummy, signed webhook.test payload to a URL you type, and it is explicitly not a job or Format run. Use it to see the shape in the Zap before any real result arrives.
What the two sides say
From Zapier: a Catch Hook accepts up to a 10 MB trigger payload (2 MB for Catch Raw Hook), answers 200 when the Zap is active, and answers 404 when the Zap is disabled or deleted, which can take up to several hours to take effect. From Sume: a delivery needs a 2xx within 10 seconds, and any other answer, including a 3xx, is a failed attempt.
| Question | Answer |
|---|---|
| Separate test URL? | No; same URL in test and live (Zapier) |
| Active Zap reply | 200 (Zapier) |
| Disabled or deleted Zap | 404, may take hours to apply (Zapier) |
| Sume test payload | webhook.test, body says it is not a job or Format run (Sume) |
| Scope for the test route | account:write (Sume) |
| Sume retries | Up to 10 attempts, longer gaps each time (Sume) |
Steps
Run these in order, once, before the campaign.
- Create the Zap with a Catch Hook trigger and copy its address.
- Call the test route with that URL, then use Zapier's test trigger to pick up the sample.
- Map the fields you need from the real shape later, since the test body has only
okand a message. - Turn the Zap on, then start one real run and confirm the terminal event arrives with the run id as
request_id.
What Sume does not do
The test delivery proves your URL answers and your verifier works. It does not prove that your field mapping matches a real receipt, because the test payload is a dummy. Sume also does not tell you the Zap is off; it only sees the 404, counts a failed attempt, and retries.
If a Zap was off during a run, the run is unchanged and you can ask for the delivery again with the redeliver endpoint after you turn it on.
Why this matters in a sale week
Because the address is shared, a test you run on Black Friday morning goes to the same place as live traffic. Keep a naming habit in the Zap, such as a filter step that ignores any event named webhook.test, so a test never triggers a paid downstream action like sending a customer email. The Sume event name is in the body, so the filter is a one-line condition.
Also remember that Zapier says disabling or deleting a Zap can take up to several hours to take effect. If you switch the Zap off to stop a flood, expect a window in which the old behavior continues, and expect Sume to keep retrying afterwards if the replies turn into errors.
Sources
Related posts
More in Integrations
- Zapier MCP costs two tasks a call: batch Sume jobs_wait first
Each Zapier MCP tool call uses two tasks. When an agent uses Sume and Zapier together, wait on all jobs in one jobs_wait, then make one Zapier call.
- Claude Code maxResultSizeChars 500,000 vs Sume's 256 KiB output cap
Raising Claude Code's per-tool result limit to 500,000 characters does not change what Sume returns: the server caps one MCP result at 262,144 bytes.
- Claude Code: local Sume entry vs claude.ai connector, who wins
Claude Code ranks a local Sume MCP entry above a claude.ai connector. That decides whether you get the API key's full tool set or OAuth's read-only one.
- claude --strict-mcp-config: run CI with only the Sume server
--strict-mcp-config makes Claude Code use only servers from --mcp-config. A CI recipe for loading just Sume's hosted MCP, with a key, a wait limit and a cap.
Written by Sume