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 input of an initial event, Docebo puts the data related to that event into a JSON message and sends it via an HTTP or HTTPS POST call (not via email or notifications) to a given URL that you configured for the webhook paired with that event.
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 webhook functionality will be expanded over time to include various integrations and additional events. Please refer to the Product Updates page for more information.
This article outlines how to activate the Webhooks app, how to create and manage webhooks, information for payloads and throttles, and other important notes that you need to know to use webhooks in your platform. To see example webhooks, events to include in your webhooks and JSON descriptions for each event, please see Webhooks Events for more information.
- This app can only be managed by Superadmins. Power Users have no permissions to view or manage webhooks.
Activating the Webhooks app
Activate the Webhooks app as described in the Managing apps and features article of the Knowledge Base. The app is listed in the Docebo Additional Features tab.
Creating, editing and deleting webhooks
Once the app is activated, you can manage it by accessing the Admin Menu, then pressing the Manage item in the Webhooks section. On the main Webhooks page, you can add and manage all of your webhooks, enable or disable them, edit or delete them and check the external system errors, if existing.
To add a webhook, press the plus button in the top right corner of the page.
In the resulting slide-out panel, give your webhook a meaningful name and in the Payload URL field, enter the URL of the webhook. You can also choose if you would like your platform to group events. For more information on grouping events, please see the Payload collection chapter in this article. Then press Next to continue.
Please Note: The type of webhook can not be changed and is always set to HTTP.
Next, in the slide-out panel, you can select up to eight events to include in the webhook, then press Create.
The new webhook will be displayed in the list on the main Webhooks page and will be disabled by default. Next, press the ellipsis icon at the end of the row where your newly created webhook is listed. In the resulting drop-down menu, press Edit.
In the following window, you will be able to edit all aspects of the webhook except for the type of webhook. If you need to change or add events to the webhook, you can press the X icon in each individual event to delete the selected event, alternatively you can press the plus button at the end of the Events list to add events using the same method as when you first created the webhook. More details on each webhook and the corresponding JSON formatted payloads for them can be found in the Webhooks Events article.
If you wish to change the destination URL or need to enable Basic Authentication for your webhook, press the Endpoint Info tab. There, in the resulting screen, you can edit the Payload URL field or, by checking the Enable Basic Auth checkbox, you can enter the username and password needed for basic authentication.
When you have finished making your changes, press the Save Changes button.
Next, after all the configuration steps have been completed, you can enable the webhook by pressing the ellipsis button at the end of the row of the corresponding webhook and in the resulting drop-down menu, press Activate.
You will notice that the status of the webhook in your lists of webhooks has been changed to Active.
If, for any reason, you need to deactivate the webhook, simply press the ellipsis button at the end of the row of the webhook and, in the resulting drop-down menu, select Deactivate.
If you wish to delete your webhook, simply press the ellipsis button at the end of the row of the webhook you wish to delete and in the resulting drop-down menu, press Delete.
You will then be presented with a confirmation message. To confirm the deletion, press the Delete button.
Notes about creating webhooks
- The Payload URL must be a properly formatted HTTP or HTTPS URL. You can insert one payload URL per webhook, and you can add up to eight events per webhook, so you can send information for more than one event to this receiving single payload URL.
- While there is no limit on how many Webhooks you create or configure, for performance reasons, you can have up to a maximum of ten webhooks enabled in your platform at any one time. Each webhook can have a maximum of eight events per webhook. Keep this in mind when creating and enabling your webhooks.
- Docebo highly recommends using HTTPS and enabling basic auth when using HTTP webhooks, as it adds security to the information that the platform sends to your endpoint.
- When dealing with basic auth and password rotation be sure to allow the old password to remain valid for some time, depending on your traffic. Old messages will authenticate using the old passwords; if you do not accept that password anymore those messages will fail.
- Always keep track of notification emails for delivery errors. If a single message fails to deliver during a 60 hour period, the webhook will be deactivated by the system. It means that no new messages will be sent by this webhook. Messages sent before the webhook was deactivated that are still in the queue will be delivered.
- Separate your webhooks on different domains (
domain2.webhook.com, etc.) to ensure that webhooks for your platform will be managed by parallel queues if you expect a high rate of messages. This is not necessary for low traffic but grouping them on different queues can optimize delivery times.
Notes about disabling webhooks
- You can only have up to ten webhooks enabled at a time, for a maximum of 80 events.
- When you disable a webhook, keep in mind that the change may not take place immediately. Webhooks form a work queue at Docebo; any work that is still running or in the work queue before the changes took place will still be sent to the configured endpoint.
Notes about deleting webhooks
- Keep in mind that deleting a webhook will completely eliminate the option to use it again in the future. If you simply do not want to run the webhook for a temporary period of time, use the disable functionality instead. Before deleting a webhook, be sure that you have received all of the information that you are needing to receive prior to confirming the deletion.
- Deleting the webhook will not delete any data that you previously sent.
When configuring or editing your webhook, the Payload Collection section is where you can define whether to group the payloads related to the events of the same type and generated by the same process in a single message delivery. For example, when this option is enabled, if a webhook includes the Course Created event, and a single API call creates ten courses in the platform, the endpoint will receive a single webhook including ten Course Created events, instead of receiving ten separate webhook messages, one for each new course.
Please Note: Enabling this option does not guarantee that the number of events included in a payload collection corresponds to the number of events generated by the triggering process (the API call, in our example). The number of events collected in webhooks changes depending on the platform infrastructure buffer optimization logic. Referring back to our example, when the API call triggers the creation of ten courses, depending on the buffer optimization logic, you may receive one webhook including a collection of ten events, two webhooks including five events each, or a webhook collecting nine events plus a single-event webhook.
When webhooks include more than one event, the webhook common property payload turns into payloads, indicating that the message includes more events. If you enabled the payload collection feature, make sure that your endpoint system is ready to receive webhooks with two different structures.
Enabling extra data for the payload
Depending on your needs, you may want to activate extra data for the payload, so that the information passed to external systems is more detailed. Extra data is available for courses, webinars, enrollments and learning plans. If you are interested in activating extra data, reach out to the Help Desk via the Help Center.
The extra data section of the payload is identified as
Notes about webhooks payloads
- Keep in mind that for performance reasons, payloads from Docebo are skinny payloads, meaning they provide basic information to your Payload URL. If you want more information, you should refer directly to the payload. You can identify the ID of the updated resources via the webhook, then call back the proper API for updates.
- The Webhooks payloads always include an
idparameter which is 56 characters long.
- Identify which webhooks events may happen after batch actions and enable grouped payloads on those. When Docebo Learn does an intensive action that triggers multiple events of the same type in a very short period of time, the webhook sent can contain multiple payloads of the same event type in one message. This ensures that there are fewer messages to deliver providing you with the ability to consume more events at a higher rate.
Responding to webhooks
In order to acknowledge the receipt of a webhook, Docebo expects a
3xx HTTP status code to be returned. Receipt of a
5xx error status code will result in the sending being logged as a failure. Please also note that if Docebo does not receive a response within 5 seconds of the request being sent, the request is considered to be, and logged as, a failure, even if the remote server may be processing the request but simply has not responded in a timely manner. Please refer to the Error Management article for more information.
Notes about responding to webhooks
- Try to respond with a
200message in the shortest time possible. The webhook delivery system has a timeout of 5 seconds, after which it considers the delivery as a failure, triggering a reschedule. If you do not send back a
200message, Docebo is unable to verify that you have received the webhook.
- On the receiving end, it is good practice to store the webhooks first, acknowledge the receipt second and then process them later. Since by nature webhooks can be sent in various orders (not necessarily chronological) and they can be sent multiple times for delivery issues, storing and processing them later allows you to filter for duplicate messages. You can use
fired_atas the date and time of the original event, and message
idas a unique identifier to spot duplicates.
Events are described in detail in a dedicated article of our Knowledge Base.
Webhooks and Audit Trail
With the Audit Trail functionality, you can track the following actions related to webhooks in your Audit Trail reports:
|Audit Trail Event||Event Description|
|Webhook created||Action logged when a webhook is created|
|Webhook updated||Action logged when a webhook is updated|
|Webhook deleted||Action logged when a webhook is deleted|
|Webhook enabled||Action logged when a webhook is enabled|
|Webhook disabled||Action logged when a webhook is disabled manually|
|Webhook disabled by the system||Action logged when a webhook is automatically disabled by the system according to the Retry Policy defined here|
Events delivery order and cardinality
Depending on the integration you plan to develop using the Docebo webhooks, you may find yourself needing to manage events in an orderly manner. For example, you want to define a webhook that sends data for creating, modifying and deleting a user.
For these operations, the order in which you receive the events is extremely important. Although Docebo will do everything possible to ensure an orderly delivery, the fault-tolerance system of the implementation does not allow Docebo to absolutely guarantee that the sending of events takes place exactly in the order in which they occurred. Therefore, we suggest implementing a system of events re-establishment before they are actually consumed by your integration.
For the same reasons, it is also necessary that you are able to discard duplicate events by making your endpoint idempotent because, under certain conditions, the webhook implementation could send the same message several times. As an example, the same event could be sent multiple times because the platform waits for 5 seconds for an answer from the endpoint before sending it again.
Notes on events delivery order and cardinality
- Make sure you are monitoring duplicated events in your platform.
- While the sending system queues the messages in real-time, it is possible that the delivery of the message may be postponed by a variable time due to the quantity of queued items and the throttling system in place.
- Although Docebo tries to minimize the waiting time before sending, the correct management of postponed messages is the responsibility of the receiver endpoint.
Throttling of messages
For performance reasons, Docebo has put certain technical limits in place to ensure that it does not send too much data to a single endpoint in a specific amount of time. Messages are dispatched at a rate of approximately one message per second.