n8n test URL or production URL: which goes in a Sume webhook_url
Put the n8n Production URL in Sume's webhook_url. The Test URL only works while the editor is listening, so a holiday batch would burn retries against it.
Put the n8n Production URL in Sume's communication.webhook_url, not the Test URL. According to the n8n Webhook node page, the Test URL registers only when you press Listen for Test Event in the editor, while the Production URL registers when the workflow is published. A holiday bulk run that points at the Test URL will deliver into a closed door as soon as you stop listening, and Sume will count each refusal as a failed attempt.
What the two URLs do
Use the Test URL once, to see the shape of a real Sume delivery in the editor. Then switch the workflow to the Production URL and publish it. The Webhook node also lets you choose when it replies, which matters because Sume needs a 2xx within 10 seconds.
| Topic | n8n (its docs page) | Sume (its docs) |
|---|---|---|
| Test URL | Registers on Listen for Test Event | Never use for a batch |
| Production URL | Registers when the workflow is published | Use as webhook_url |
| Response modes | Immediately, When Last Node Finishes, Respond to Webhook node, Streaming | Needs 2xx within 10 seconds |
| Authentication options | Basic, Header, JWT, None | Signature header sume-v1=; verify it yourself |
| Max payload | 16 MB (N8N_PAYLOAD_SIZE_MAX when self-hosted) | Payload is null above 1 MiB, with a result_url |
| Retries | Not applicable | Up to 10 attempts, no redirects |
Steps
Set it up so the first holiday delivery is not the first real test.
- Create a Webhook node with the POST method and copy its Test URL.
- Send a Sume test delivery to that URL with
POST /v1/webhooks/test-deliveries, which sends a signedwebhook.testpayload, and inspect it in the editor. - Choose a response mode that answers quickly; Immediately is the natural fit for a Sume delivery, since the work can happen after the reply.
- Publish the workflow, copy the Production URL, and use it as
communication.webhook_urlon the runs.
What Sume does not do
Sume does not check that your URL is a test URL or a live one; it only needs a public HTTPS address that answers 2xx. It also does not follow redirects, so if your n8n instance sits behind a redirecting front door, register the final address. After ten refused attempts the delivery status becomes exhausted, and the run itself is unchanged, so you can fix the URL and use the redeliver endpoint for that run.
Sume does not verify your n8n authentication choice either. If you protect the node with Header or Basic auth, the Sume docs we read describe only the signature headers on a delivery and no custom credentials, so the practical option is None plus a signature check inside the workflow.
A pre-flight check
Before a sale weekend, send one real run with the Production URL and watch it arrive in the execution list. Then confirm the receipt shows webhook_delivery.status of delivered. If it shows retrying or exhausted, read last_status_code and last_error on the receipt, which tell you what your endpoint answered.
Sources
Related posts
More in Integrations
- Unattended agent on Sume MCP: API key or OAuth consent?
A cron or CI agent cannot click a consent page. Sume's docs give OAuth to interactive clients and API-key remote MCP to automation, with caps set per call.
- One Sume MCP URL in Claude Code, Cursor and VS Code: keys compared
One https://mcp.sume.com/mcp URL, three shapes: claude mcp add --transport http, Cursor's mcpServers url, and VS Code's servers with type http.
- One Sume webhook endpoint for job and run events: route on event
Job and run webhooks share one HMAC scheme but not one payload. A 27-line TypeScript handler verifies once, routes on event, and answers 204 to the rest.
- Stdlib Python Sume webhook receiver: http.server, 204 for webhook.test
A 29-line http.server receiver that refuses an empty secret, checks sume-v1 in a 300-second window, takes the two-signature header, and 204s webhook.test.
Written by Sume