Webhooks Security

IP whitelisting

Feezback webhook calls originate from a fixed set of IPs per environment — whitelist them on your endpoint or you will silently miss webhooks. Full details on Webhooks & IP Whitelisting; quick reference:

Environment	IP(s)
Integration	`34.250.136.225`
Production	`54.78.124.183`, `54.228.71.93`, `51.17.181.171`

If you're not receiving webhooks at all, this is the first thing to check.

Optional, stronger authentication

configured per client during onboarding. IP whitelisting alone isn't your only option. Ask your Feezback integration contact to enable any of the following on your webhook endpoint:

Mechanism	How it works	You provide
Custom headers	Feezback attaches static header(s) — e.g. an API key or shared-secret value — to every webhook call to your endpoint	The header name(s) and value(s)
Mutual TLS (mTLS)	Feezback presents a client certificate on every connection to your endpoint, which you can validate server-side	A certificate + private key pair
OAuth2 bearer token	Feezback calls your own token endpoint first to obtain an access token, then sends `Authorization: Bearer {token}` on the webhook call — your auth server is the source of truth	Your token endpoint URL, plus any headers/body it needs

These are opt-in and set up per client — they aren't exposed as self-service settings, so provide the values to your integration contact.

TLS certificate verification can also be disabled per client — this exists mainly for testing against self-signed certs and is not recommended for production.

Delivery reliability. Webhook delivery to your endpoint is retried a small number of times automatically with backoff if your endpoint errors or is unreachable. If you suspect you missed webhooks during an outage on your side, you can poll a transaction/consent status by calling the relevant endpoint.