User-event Webhooks

This feature needs to be specifically enabled. With user-event webhooks, you can register specific URLs to be called on specific user actions or events, such as a sign-up, deletion of an account, etc. There are two kinds of webhook: pre-event and post-event.

Post-event webhooks

Post-event webhooks trigger after the event has been processed.

This implies that there is no way a post-event webhook can modify an event or prevent it, as everything is already done when the webhook URL is called. On the other hand, this allow post-event webhooks to be fully asynchronous: the API returns a response and the user can continue browsing your application without waiting for an answer from the URL. For this reason, you should always prefer post-event webhooks whenever possible.

In case of a failure, there is no impact for the end use. Depending on what happened on your end, you may need to resynchronize your data with the data we have.

Pre-event webhooks

Pre-event webhooks trigger before an event has been processed (before saving, or deleting, or updating the user profile).

This allows the webhook URL to send back a response with additional data, or to prevent the event to proceed altogether. However, this implies that a pre-event webhook will suspend the API response and keep the user waiting. In addition to the usual time it takes to handle the event, they will have to wait for the URL to process and answer the call, which is usually significantly longer due to network latency. You should therefore be quite aggressive on the configured timeout, to prevent a user from being stuck (default timeout is 10 seconds, which is probably the maximum value you would want).

In case of a failure, we can either continue to process the event as if there was no webhook involved, or prevent the event from being processed and have the API return an error message. You can set the behavior you wish when configuring the webhook. The first choice is the most robust, as the user will not be stuck, but it might result in desynchronized data. The second choice guarantees data will stay consistent on both sides.

Pre-event are currently limited to some type of events, and are not available for others. See the configuration page for details.