Webhook delivery now blocks private and internal URLs

The webhooks service now performs an SSRF check before dispatching any outbound webhook. URLs that resolve to a literal IP address, loopback addresses, link-local addresses, or RFC 1918 private network ranges are rejected with a clear error.

This change closes a class of server-side-request-forgery vectors where a customer could register a webhook pointing at our internal infrastructure (or at another tenant’s private network) and have FastPix dispatch traffic on their behalf.

What this means for you:

• Webhooks must point at a publicly routable hostname or IP. We resolve and validate the destination at registration time and again at dispatch time.
• If you previously used a webhook URL that pointed at 127.0.0.1, localhost, 10.x.x.x, 172.16.x.x – 172.31.x.x, or 192.168.x.x, those endpoints will now fail to deliver. Move the receiver to a public host (or use a tunnel like ngrok during development).
• The Content-Type header on outbound webhook requests now explicitly includes charset=utf-8 for parity with common receivers that are strict about charsets.

We consider this an incompatible change for customers relying on private destinations, and labelled it breaking to call that out.