Introduction

In Docebo, you can create webhooks to trigger once an event occurs in your platform, sending you information about that event to a specific Payload URL. This allows you to collect data from your learning platform to build reports, integrations, dashboards and more. You can, for example, also connect to your human capital management system (HCM), email non-Docebo Learn users about actions that occur within the platform or update your content storage management.

Once you’ve activated the Webhooks app in your platform, you can create an initial event, then Docebo sends you a post to a given URL that you set for the webhook paired with that event. Docebo puts the data related to that event into a JSON message and sends it to you via an HTTP or HTTPS POST call (not via email or notifications). You can also create webhooks via the full set of webhook APIs provided by Docebo. Refer to the official API documentation for more information. 

Webhook functionality will be expanded over time to include various integrations and new events, as communicated via the Product Updates page.

Questions and answers

This section is a collection of the most frequently asked questions about creating and managing Webhooks.

What is the best way to approach writing webhooks?

Always try to think about webhooks as notifications, not API calls. A webhook is an alert that something has happened. The alert is then passed on to a third-party system which processes it according to the needs of the integrator. Webhooks should not be written as if they were an automatic API call to directly trigger actions remotely as they do not always happen in real-time.

How many events can be in a single payload when they are grouped together?

The number of events of the same type are grouped by the system based on its performance with a maximum of 25 events per grouping. Please note that Docebo reserves the right to limit the number of payloads per group for infrastructure performance reasons.

How long do we wait for a response before a “non-response” is deemed the same as a failure?

When the webhook is started, the integrator MUST respond in 5 seconds otherwise the webhook goes in the retry queue (the retry queue will attempt to resend the message up to 10 times within the next 48 hours).

How large can the queue of webhooks get before there is a truncation? Is there a threshold of the number of messages that can be sent out (discounting limitations of the receiving server)? What is the risk of messages being purged from the queue with extremely large volumes?

From a client perspective there are no limits so there is no risk of messages being purged. The messages are lost ONLY in the event of the receiving endpoint failing to respond with a “200” reply during the 10 retries within the 48 hour period, as mentioned in the previous answer.

Does a single message have to be identified as a success or failure before a subsequent message is sent? Will we send a second message before we get the return response for the first message?

Every message is independent of the others; however after 10 retries with the same payload, the webhook gets deactivated (see question "How long do we wait for a response before a “non-response” is deemed the same as a failure?"). 

Are the messages sent sequentially (one after the other) or on demand (pushed without consideration of the status of other messages)?

The system organizes the queues based on the domain part of webhook endpoints. It then manages the priorities of the messages of each queue. As a result, the second message sent waits for a 5-second timeout before it begins. 

Are messages at rest in the queue encrypted?

They are not encrypted but they are protected by our infrastructure with a fair authentication. The transmission itself uses the HTTP or HTTPS protocols set for the webhook endpoint by the administrator.

Is the queue killed when there is a critical failure? What is the risk of messages being lost/undelivered?

Generically speaking, the queue is never killed. The risk of a “lost message” or “not delivered” is extremely low however, these messages could be caused by a development issue on the integrator side.