Creating and Managing Webhooks

Discover how to create, manage and send webhooks in your platform

Last Updated

January 29th, 2021

Docebo Module


Reading Time

8 min

User Level


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.

For performance reasons, you can have only ten webhooks enabled in your platform at one time. Each webhook can have only eight events per webhook. Keep this in mind when creating and enabling your webhooks.

This article outlines how to activate the Webhooks app, how to create and manage webhooks, events to include in your webhooks, JSON descriptions for each event, information for payloads and throttles, and other important notes that you need to know to use webhooks in your platform.

The Webhooks app is available for Enterprise customers only, and this app can only be managed by Superadmins. Power Users have no permissions to view or manage webhooks.

Activating the App

Login to your Docebo platform as the Superadmin. Access the Admin Menu from the gear icon in the header of your platform, then select the Add New Apps item in the menu. Once you’re in this area, select the Additional Features tab in the tab menu on the left side. Then, find the app in the list and press the Activate App button.

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

To add a webhook, press the plus button in the top right corner of the page. On the configuration page, begin in the General section. Add a Name for your webhook. This is the name used internally inside of your platform, so you can give it any identifiable name that you choose. Then, add the Payload URL to where the information from the webhook will be sent.

The Payload URL must be a properly formatted HTTP/S 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.

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. More details on each webhook and the corresponding JSON codes for them. You will then see the Events field populate with your selected events, and you can remove them at any time using the X icon next to each event.

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

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.

Finally, move to the Payload Collection section, 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. As an 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. Going 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.

Responding to Webhooks

To acknowledge the receipt of a webhook, Docebo expects a 2xx HTTP status code in response or a 3xx HTTP status. In any other case, Docebo will mark the sending as a failure. Please refer to the Error Management article for more details.

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 your Customer Experience Manager (if your plan includes this option) or contact us via the Communication Center

The extra data section of the payload is identified as extra_data.


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 the 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. Note also that deleting the webhook will not delete any data that you previously sent.

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

Enabling or Disabling Webhooks

The checkmark 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 grey checkmark means that the webhook is disabled and will therefore not trigger.

Simply press the checkmark in the webhook row to enable or disable it. Remember that you can only have up to ten webhooks enabled at a time, for a maximum of 80 events.

Important Notes about Disabling Webhooks: When you disable 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.

Webhooks and Audit Trail

If the Audit Trail app is active on your platform, you can activate the tracking of the following actions related to webhooks in your Audit Trail reports:

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

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. Make sure you are monitoring duplicated events in your platform.

Please note that the sending system queues the messages in real-time, but the delivery of the message can 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.

Payload Notes

Keep in mind that for performance reasons, payloads from Docebo are skinny payloads, meaning that it provides basic information to your Payload URL. If you’re wanting 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.

Throttling Notes

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.

Please Note: In case your endpoint is not able to handle the amount of data sent by Docebo in a given time, you will receive a 426 response code or other codes. These codes generally mean that everything is in range from Docebo’s side, but your endpoint is not capable of receiving the amount of data sent. When this happens, Docebo will continue retries throughout the normal Exponential Backoff Policy, but retries will end after the normal cycle if no responses are received.