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 also connect to your HCM, email non-LMS users about actions that occur in the platform or update your CSM. Once you’ve activated the Webhooks app in your platform, you can create an input of 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 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. Note that more webhook functionality will be built over time to include various integrations and more events, so stay tuned the Product Updates page in the future.
Questions & Answers
This section is a collection of the most frequently asked questions about creating and managing Webhooks.
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 above).
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/S protocol 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 the “lost message” or “not delivered” is extremely low however it could be caused by a development issue on the integrator side.