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 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.

Important Information

• This app can only be managed by Superadmins. Power Users have no permissions to view or manage webhooks.

Activating the 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 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. On the configuration page, start in the General section. Add a Name for your webhook which can be any identifiable name of your choice as it is used only internally in your platform. Then, add the Payload URL to where the information from the webhook will be sent.

In the Events section, press the Select Events button to add events to the webhook. In the slideout panel, flag up to eight events to include in the webhook, then press Confirm. You will then see the Events field populate with your selected events. You can remove the events at any time using the X icon next to each event. More details on each webhook and the corresponding JSON codes for them can be found in the Webhooks Events article.

In the Authentication section you can switch the toggle to Enable Basic Auth for your receiving endpoint. If enabled, you will need to insert your basic auth username and password in the corresponding fields in the Protocol Info section.

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 that 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 eight 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 enable the payload collection feature, make sure that your endpoint system is ready to receive webhooks with two different structures.

Once you’ve finished configuring your new webhook, press the Save Changes button to create your webhook. The new webhook will be displayed in the list on the main Webhooks page and will be disabled by default. Refer to the corresponding sections below for how to disable, re-enable, edit or delete your webhooks.

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 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 (domain1.webhook.com, 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.

Webhooks Payloads

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 extra_data.

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 id parameter 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 2xx or 3xx HTTP status code to be returned. Receipt of a 4xx or 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 200 message 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 200 message, 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_at as the date and time of the original event, and message id as a unique identifier to spot duplicates.

Events

Events are described in detail in a dedicated article of our Knowledge Base.

Editing or Deleting Webhooks

All of your webhooks will appear in the list on the main Webhooks page. Once created, you can edit any of the information that you configured at any time. Scroll your mouse over the webhook in the list, then press the ellipsis icon in the webhook row. In the dropdown menu, select the Edit item.

You’ll be redirected to the configuration page of the webhook, where you can edit any of the fields that you previously configured, including the name, Payload URL, events in the webhook, and the basic auth information. When finished with your edits, press Save Changes.

To delete a webhook, scroll your mouse over the webhook in the list, then press the ellipsis icon in the webhook row. In the drop-down menu, select Delete item. Confirm your choice in the pop-up message by flagging that you want to proceed and pressing Confirm.

>Keep in mind that deleting a webhook will completely eliminate the option to use it again in the future. If you are simply not wanting to run the webhook for a temporary period of time, use the disable functionality instead. Before deleting a webhook, be sure that you’ve received all of the information that you’re needing to receive prior to confirming the deletion.

Notes about Editing or Deleting Webhooks

• When you edit or delete a webhook, keep in mind that the change may not take place immediately. Webhooks form a work queue for Docebo, so any work that is still running or in the work queue before the changes took place will still be sent to the configured endpoint for the webhook at the time that the webhook triggered.
• Deleting the webhook will not delete any data that you previously sent.
• When copying or moving a webhook, keep in mind that the copied or moved webhook will become deactivated and must be reactivated again.

Enabling or Disabling Webhooks

The check mark in a webhook Status column on the main Webhooks page allows you to quickly view and change which webhooks are currently enabled or disabled. A green checkmark means that the webhook is enabled to run, while the gray checkmark means that the webhook is disabled and will therefore not trigger.

Press the checkmark in the webhook row to enable or disable it.

Important 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.

Webhooks and Audit Trail

With the Audit Trail functionality, you can track the following actions related to webhooks in your Audit Trail reports:

Further details on the Audit Trail report.

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, suppose 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’s 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 doesn’t 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.