About Passfort's webhooks
Enable webhooks to get a real-time notification when something happens in Passfort.
Every webhook is triggered by an event in Passfort. Different webhooks send payloads for different events.
When a webhook is triggered by an event, it sends a payload to an endpoint you choose. The payload contains key information about what change occurred.
Note that webhooks cannot be sent directly to a Salesforce endpoint because Salesforce interprets our Authorization header as an attempt to authorize requests in Salesforce. Any requests directly to a Salesforce endpoint will be rejected with a 401 Unauthorized Error. To work around this, send requests through an intermediary or use a webhook-altering tool.
Batching
When batching is enabled, multiple webhooks are delivered in a single request.
Webhook messages are added to a queue, and Passfort delivers the first 100 messages in the queue approximately every 0-10 seconds.
We recommend enabling batching - particularly for high-volume customers - because it's the fastest option. Without batching, webhooks are sent one at a time, in the order they were triggered.
About receiving webhooks
Allow listing the webhook IP address
Webhook payloads are sent from different IP addresses depending on the server you use:
For users of the Brussels, Belgium, EU location, the IP addresses are
35.195.138.186,130.211.56.13, and35.195.211.38.For users of the Dubai, UAE location, the IP address is
20.74.180.162.For users of the South Carolina, USA location, the IP addresses are
35.231.204.101and35.196.25.242.
For server details, see Server and sign in details.
If you're block-listing other IP addresses, you should add this IP address to your allow list to ensure you can receive webhooks.
Authenticating the request
When you receive a payload, you should ensure the secret in the payload matches the secret you added when you configured your webhooks.
The shared secret is sent in two places in the payload:
As a parameter in the webhook response.
As an HTTP Authorization header with the bearer type.
Returning a 200 response
The webhooks have guaranteed ordering, and we'll retry delivering webhook payloads until we receive a 200 response from you.
If you have batching disabled and a webhook cannot be sent, the webhook is retried using the following exponential backoff parameters while any other waiting webhooks are queued behind it:
For the first 12 attempts, the webhook is retried after 30 seconds * power(2, attempts -1)
After this, the webhook is retried daily.
When batching is enabled, a single request is sent containing multiple webhooks in an array. These are the first 100 webhooks in your queue. Once we receive a 200 response from you, we will remove these webhooks from your queue. If we do not receive a 200 response, those webhooks will remain in your queue and will be included in the next batch request. The batch request is retried using the same exponential backoff parameters described here.
To prevent a backlog, we recommend that your webhook receiver returns the 200 response immediately and that you add the webhook payloads to a queue managed by a separate process. To avoid processing webhooks twice, your queue should remember the last webhook ID that was processed and ignore any webhooks sent before that.
If your webhook receiver takes too long to send a 200 response, the webhook or queue will time out. When batching is enabled, your 200 response should be sent in 5 seconds or less. When batching is disabled, your response should be sent in 10 seconds or less.
The webhook status queue
The webhook status queue indicates whether your webhook events are sending as expected.
Queue: Whether the queue of payloads is Empty, and therefore the webhooks are working as expected, waiting to send a specific number of payloads, or Stalled, meaning that payloads are not being sent.
Last processed: How long it has been since the last webhook payload was sent.
Recent failures: If any payloads are waiting to send, this list displays the 10 most recent payloads that are waiting.
Select to clear any Recent Failures from the list.
If the webhook status queue is stalled, you can resolve it by following the steps described in Resolve a stalled webhook status queue.
We do not advise disabling, then re-enabling the Webhooks enabled checkbox when you're troubleshooting because this may result in a loss of webhooks. Instead, use the button to force the system to retry webhooks immediately and ignore any exponential backoff that might be in place.