Configure Model Registry Webhooks¶

A webhook is like a real-time messenger between different software applications. In the Model Registry, webhooks promptly notify other systems or services about changes to your machine-learning models. This means you can deploy models, update documentation, or send notifications automatically. By using webhooks, you can streamline workflows, boost efficiency, and enhance collaboration.

Furthermore, webhooks are flexible. You can attach them to any model within the Model Registry and assign multiple webhooks to a single model.

Create and edit webhooks¶

If you want to add or edit a webhook, first open the Model Registry and click on the model of your choice:

Then click on the Webhooks tab that will show you the list of the Webhooks currently configured for the current model:

You can create a new Webhook by clicking on the "Create Webhook" button on the right of the screen.

If you want to edit a Webhook, you can click on the Webhook Menu (⋮) and click on "Edit".

Webhook configuration¶

In the Webhooks modal, you can edit a webhook configuration.

The configuration fields are:

• Webhook name: A descriptive name for your webhook.
• URL: The destination where payloads will be sent.
• Secret (Optional): A token to secure the connection.
• Triggers events: Events that activate the webhook. See below for more details about the different triggers.
• Headers (Optional): Additional HTTP Headers sent with the request.
• GitHub Actions Integration (Optional): If enabled, the payload will be sent to a format compatible with triggering a Github Action. Check out Github documentation for more details.

Webhook triggers and payload¶

Webhook can be configured to be triggered on various events of a Model lifecyle:

• Model version created: The webhook will be triggered for every new model version registered.
• Model version deleted: The webhook will be triggered for every model version that is deleted.
• Model tag changed: The webhook will be triggered for every tag that is added or removed from a model version.
• Model status changed: The webhook will be triggered after a model status change is approved or forced by a workspace admin.

For each event, the payload will contain the same fields with some minor differences:

Webhook security¶

Optionally, you can configure a secret token for each Webhook to ensure data integrity and authentication. If configured, this token will be included as the Authorization header in the request. It's your server's responsibility that the secret value match the expected value.

Test webhooks¶

You can easily test your Webhook configuration by clicking the "Test Webhook" button. This will send a sample payload with the "TEST" trigger. You can then review the test results to verify proper setup.

Here is how it would look if the test call succeeded:

Here is how it would look if the test call fails:

In that case, the tooltip will show you some information about the response. If you need more details, you can click on the "Copy full response" at the bottom of the tooltip to get a more detailed version to understand why the test call failed.

Test the payload¶

When using the test functionality, the event triggered will how the following payload:

Access webhooks programmatically¶

You can retrieve webhook configuration with the following endpoint.

You can create or update a webhook using the following endpoint.