n8n 3.0 SSRF blocklist adds 100.64.0.0/10: Sume webhook paths

Calls from n8n to Sume's public API are unaffected by n8n 3.0's wider SSRF blocklist, but anything that tries to reach an address in 100.64.0.0/10 will now be blocked. The 3.0 breaking-changes page says the blocklist now includes that range. The reverse direction needs a check too: Sume only delivers webhooks to a public HTTPS URL.

What changes in n8n 3.0

Outbound to Sume

https://api.sume.com/v1 and https://mcp.sume.com/mcp are public hosts, so the HTTP Request node reaches them as before. If you route through an internal proxy that resolves into the newly blocked range, calls would be refused by n8n before leaving. Check the proxy address.

Inbound from Sume

Sume requires a public HTTPS webhook URL and does not follow redirects. Each attempt has a 10 second timeout, with up to 10 attempts. A self-hosted n8n whose Webhook node is reachable only on a private overlay network cannot receive these. Expose the Webhook path through a public HTTPS endpoint, then verify the signature in the first node after it.

• Compute HMAC-SHA256 over <timestamp>.<raw_body> using SUME_COM_WEBHOOK_SIGNING_SECRET.
• Compare to each sume-v1= entry in the signature header.
• Dedupe on job_id, or run_id for run events.

Quick validation

After upgrading, send POST /v1/webhooks/test-deliveries to your n8n webhook URL. If it arrives, your path is public. If a real delivery was missed, POST /v1/jobs/{id}/webhook/redeliver with jobs:write resends it. Polling /status is the backup.