Webhooks
NOTE Webhooks is a Sentinel EMS add-on feature available with an active webhooks subscription plan.
|
>About Authentication Profiles
|
What Is a Webhook?
Webhooks enable Sentinel EMS to notify client applications (or services) about a new creation, an update, or a deletion of a Sentinel EMS entity. Through webhooks, Sentinel EMS sends event notifications to subscribed applications, allowing them to automatically respond to business events and perform relevant actions in real time. For example:
>Triggering automated workflows
>Enabling third-party integrations
>Enhancing real-time data synchronization
>Supporting business intelligence and reporting
In Sentinel EMS, webhooks support OAuth and Basic authentication to send HTTP requests to the client applications.
Prerequisites for Creating a Webhook
Only Sentinel EMS administrators can create webhooks. An authentication profile (Basic or OAuth) is required by webhooks to authenticate to the client applications. You can also define an authentication profile when creating a webhook.
What Is an Event?
An event is triggered whenever an operation is performed on a Sentinel EMS entity, such as when a new entitlement is added or an existing entitlement is expired. A webhook allows you to create a subscription to these events. Through webhooks, organizations can subscribe to these critical events to enable real-time data synchronization and business process integration across connected systems.
For example, if you subscribe to the Entitlement Added event, you will receive detailed information (in JSON payload) for every new entitlement added in Sentinel EMS.
You can create webhook subscriptions for the following events, where "Contact" refers to the User entity, and "User" refers to the Vendor User entity.
Event Data
A webhook subscribes to a Sentinel EMS event. When the subscribed event occurs in Sentinel EMS, the webhook delivers its data in JSON format to the configured URL in an HTTP POST request.
The following are a few samples showing examples of the event data that webhooks deliver to the client application URL.
Example for the "Add Namespace" Event:
{
"eventName": "Namespace Added",
"entityName": "Namespace",
"webhookId": "08c61b38-8523-4eb1-9b01-b12a2e6a583c",
"webhookName": "NSADD",
"activityName": "Add Namespace",
"requestId": "9876f57e-58d7-460d-bc39-06d6ee65be1b",
"eventId": "5c9d6072-b5bf-4640-8aae-422a52847994",
"url": "https://emstm02.highend.engg-services.com/ems/api/v5/namespaces",
"entityId": "e60db72f-a446-43cb-9a25-0d8c36fe7b3b",
"currentState": "{\"namespace\":{\"id\":\"e60db72f-a446-43cb-9a25-0d8c36fe7b3b\",\"createdBy\":\"admin\",\"creationDate\":\"2025-07-23 10:01\",\"lastModifiedBy\":\"\",\"lastModifiedDate\":\"\",\"name\":\"EDUCTATIONAL\",\"description\":\"\",\"state\":\"DRAFT\",\"refId1\":\"\",\"refId2\":\"\"}}",
"httpMethod": "POST",
"performedBy": "admin",
"actualUser": "admin",
"tenantId": "97553b1b-f8e5-4fb0-8e21-59f19d4a6640",
"creationDateTime": "2025-07-23 10:01",
"operation": "Create",
"opDatetime": "2025-07-23 10:01:33.437"
}
Example for the "Update Namespace" Event:
{
"eventName": "Namespace Updated",
"entityName": "Namespace",
"webhookId": "9788bfb9-14d3-494c-b583-f27280b3e367",
"webhookName": "NSUPD",
"activityName": "Replace Namespace",
"requestId": "8edffd14-7f60-4f7a-9390-4cb645f5f4d7",
"eventId": "aee827d7-d1e6-4ae8-ab9b-db5791ab3bda",
"url": "https://emstm02.highend.engg-services.com/ems/api/v5/namespaces/e60db72f-a446-43cb-9a25-0d8c36fe7b3b",
"entityId": "e60db72f-a446-43cb-9a25-0d8c36fe7b3b",
"previousState": "{\"namespace\":{\"id\":\"e60db72f-a446-43cb-9a25-0d8c36fe7b3b\",\"createdBy\":\"admin\",\"creationDate\":\"2025-07-23 10:01\",\"lastModifiedBy\":\"\",\"lastModifiedDate\":\"\",\"name\":\"EDUCTATIONAL\",\"description\":\"\",\"state\":\"DRAFT\",\"refId1\":\"\",\"refId2\":\"\"}}",
"currentState": "{\"namespace\":{\"id\":\"e60db72f-a446-43cb-9a25-0d8c36fe7b3b\",\"createdBy\":\"admin\",\"creationDate\":\"2025-07-23 10:01\",\"lastModifiedBy\":\"admin\",\"lastModifiedDate\":\"2025-07-23 10:02\",\"name\":\"EDUCTATIONAL\",\"description\":\"educational
items\",\"state\":\"DRAFT\",\"refId1\":\"\",\"refId2\":\"\"}}",
"httpMethod": "PUT",
"performedBy": "admin",
"actualUser": "admin",
"tenantId": "97553b1b-f8e5-4fb0-8e21-59f19d4a6640",
"creationDateTime": "2025-07-23 10:02",
"operation": "Update",
"opDatetime": "2025-07-23 10:02:30.409"
}
Example for the "Product Key Quantity Exhausted" Event:
{
"eventName": "Product Key Quantity Exhausted",
"entityName": "Entitlement",
"webhookId": "320d390f-0360-4149-b69d-bcadcf2ce8b3",
"webhookName": "PKIDQTYEXHT",
"activityName": "Add Activation",
"requestId": "d8f9df9d-4d86-4d92-a71c-e6b396834eb7",
"eventId": "e0d78fdb-6b3e-427a-92d1-51b666ddc9ab",
"url": "http://emstm02.highend.engg-services.com/ems/api/v5/activations/bulkActivate",
"entityId": "9d03e346-82eb-4059-b95e-1b1e205ca07b",
"httpMethod": "POST",
"performedBy": "admin",
"actualUser": "admin",
"tenantId": "97553b1b-f8e5-4fb0-8e21-59f19d4a6640",
"creationDateTime": "2025-07-23 10:04",
"operation": "Update",
"opDatetime": "2025-07-23 10:04:14.760"
}
The parameters included in the event data are:
>eventName: Name of the subscribed event.
>entityName: Name of the Sentinel EMS entity for which the event occurred.
>webhookId: Unique identifier of the webhook.
>webhookName: Name of the webhook.
>activityName: Name of the activity that causes the event. For example, "Add Feature" and "Bulk Feature Upload" activities result in the "Feature Added" event.
>requestId: Unique identifier of the HTTP request sent to Sentinel EMS and from Sentinel EMS to client applications.
>eventId: Identifier of the subscribed event in Sentinel EMS.
>url: URL of the Sentinel EMS endpoint that is called for the event to happen.
>entityId: Identifier of the Sentinel EMS entity for which the event occurred.
>httpMethod: HTTP method of the operation performed that resulted in this webhook event.
>currentState: State (JSON) of the entity after the event occurred. It is blank for "Delete" events.
>previousState: State (JSON) of the entity before the event occurred.
>operation: Name of the operation. For example, create, update, delete.
>opDatetime: Time at which the event occurred in milliseconds.
NOTE
>The current state and previous state are included in the event data only if Include Data is set to Yes in a webhook.
>The Entitlement Expired event contains full entitlement payload only in the current state.
>The payload of the Product Key Quantity Exhausted event does not contain all the product keys for an entitlement. It contains selective entitlement fields for entitlement, customer, contact (representing the user entity), channel partner, product keys, and custom attributes, without any feature details.
>When an individual product key expires, then the Product Key Expired event is sent. When an entitlement expires, all the product keys in the entitlement also expire, however, only the Entitlement Expired event is sent.
>To configure the time zone in which the Entitlement Expired and Product Key Expired events occur, set the Time Zone for Expiration Events admin console property.
Built-in Retries for Webhooks
Webhooks may fail to deliver event data for various reasons, such as authorization failures or unreachable servers. Sentinel EMS automatically retries the delivery to the client URL up to three times. This retry mechanism cannot be configured, and retries occur at predefined intervals.
While retries are in progress, the associated events are marked as in progress. During this period, the event data cannot be retrieved through the API or any manual process. The retry process can take up to one hour to complete. If all three retry attempts fail, the event is marked as failed.
You can view details of both successful and failed events using the Search Event API endpoint, as described in the Sentinel EMS REST API Reference . You can query events by state, creation date with time precision (YYYY-MM-DD HH:MM), or unique identifiers associated with a webhook or event.
If required, you can use the Retry Event API endpoint, as described in the Sentinel EMS REST API Reference, to reprocess both successful and failed events based on filters you define. This allows you to trigger up to three additional delivery attempts for every matching event, regardless of its current delivery status.
You can mark failed events as successful using the Mark as Bulk Successful API endpoint, as described in the Sentinel EMS REST API Reference. This action removes the selected events from the failed list, helping maintain cleaner operations and faster recovery.
Webhook Status
By default, a webhook is enabled. You can disable a webhook if you want it to stop sending the event data to the client application.
Creating a Webhook
To create a webhook:
1.From the navigation pane, select Configuration > Webhooks to view the Webhooks page.
2. Click Add Webhook. The Add Webhook page opens.
3.Fill in the webhook attributes and click Save.
Webhook Attributes
The following table explains the attributes that are used to create a webhook:
| Attribute | Description | Required/Optional | Valid Values |
|---|---|---|---|
| Event |
Name of the event subscribed by the webhook. |
Required |
>A list of predefined events |
| Name |
Unique name of the webhook.
|
Required |
>Maximum: 100 characters >Alphanumeric >Special characters |
| Endpoint URL |
The URL of the client application to which the webhook posts the event data in the form of JSON. |
Required |
>Maximum: 2000 characters >Alphanumeric |
| Authentication Profile |
Name of the authentication profile associated with the webhook. Enter a space to view the list of available authentication profiles. Select an authentication profile from the displayed list or click the |
Required | A new or an existing authentication profile |
|
|
Trigger Conditions for the event notification. You can define trigger conditions only for the following events: >Entitlement Added >Entitlement Updated >Activation Added >Activation Updated NOTE When no trigger condition is defined, the webhook is triggered for every event. |
Optional | |
| Description | A user-friendly description to identify the webhook. | Optional |
>Maximum: 500 characters >Alphanumeric |
| Include Data | Specifies whether to include previous and current states of the entity (for which the event happened) in the event data sent to the endpoint URL. | Optional |
Yes OR No Default: Yes |
| Enable Webhook | Determines whether the webhook can post event data to the endpoint URL. | Optional |
Yes OR No Default: Yes |
Add Authentication button to create a new one. For details, see Trigger Conditions
When creating or editing a webhook, you can define trigger conditions. Webhook trigger conditions allow you to define specific conditions that determine when a webhook should be processed. This removes the need for external filtering or dispatcher services by enabling you to configure conditions directly within the webhook definition.
You can use trigger conditions to implement selective event handling, such as filtering events for specific products, customers, partners, or market groups, based on attributes such as product mappings or geographical regions. This ensures that only relevant events trigger the webhook, improving efficiency and reducing unnecessary processing.
Click the Manage Trigger Conditions 
button next to Trigger Conditions to open the following dialog box:
You can define webhook triggers using the Manage Trigger Conditions dialog box.
| Control | Description |
|---|---|
| And/Or |
Specifies the logical operator that connects multiple conditions. >And: The webhook triggers only if all specified conditions are true. >Or: The webhook triggers if any of the specified conditions is true. |
| Add Condition (+) | Adds a new condition to the current group. Each condition consists of an alias field, an operator, and a value. |
| Add Filter Group |
Adds a nested group of conditions, allowing you to combine multiple sets of conditions using And/Or logic. |
| Condition Row |
Enables you to set the following: >Aliases: The list displays all supported fields for the selected event (as selected in Webhook Attributes). Select a field to build a condition, for example, Activation Comments. After you save the condition, all aliases used in it are automatically converted to their corresponding JSON values. >Operator: Select the comparison operator—Is not equal to or Is equal to. >Value: Enter the value to be used for comparison. The condition is evaluated against the given value without validating the value. The condition triggers only when the entered value is valid. |
| Delete button |
Removes a condition or group. |
| Save |
Saves the defined trigger condition and returns to the Webhooks page, where the condition is converted into a corresponding JEXL expression. You can copy this expression using the Copy to Clipboard option in the Webhooks page. |
| Cancel |
Discards changes and closes the dialog box. |
Managing Trigger Conditions—A Walkthrough
The following expression comprises a nested set of conditions:
((entitlement.customer.name == 'TestCustomer' && entitlement.state == 'Enable') || (entitlement.contact.externalId == 'UserExternalId'))
To create this expression, perform the following steps in the Manage Trigger Conditions dialog box:
|
1.Click the Delete button to remove the existing condition row. |
|
|
2.Click Add Filter Group twice to create two filter groups, under which you can define multiple sets of conditions. |
|
|
3.Click Add Condition twice to create two condition rows in the first filter group. |
|
|
4.Set the following values in the newly added condition rows: 1st Condition Row: •Alias: Customer Name •Operator: Is equal to •Value: TestCustomer 2nd Condition Row: •Alias: Entitlement State •Operator: Is equal to •Value: Enable |
|
|
5.Click Add Condition to add a new condition row in the second filter group. |
|
|
6.Set the following values in the newly added condition row: •Alias: User ExternalId •Operator: Is equal to •Value: TestCustomer |
|
|
7.Click Save. |
Defining Trigger Conditions Using the Sentinel EMS REST API
You can use the Add Webhook, Replace Webhook, and Update Webhook APIs, as described in the Sentinel EMS REST API Reference, to define trigger conditions. These APIs offer greater flexibility by supporting advanced JSON path navigation operators.
For example, when using the API, you can include both the [*] array wildcard and [index] indexed array access. In contrast, trigger conditions created through the Manage Trigger Condition dialog box support only the [*] operator. As a result, if a trigger condition is defined through the Sentinel EMS REST API and contains symbols other than [*], it can only be modified using the API, not through the Sentinel EMS vendor portal.
The following symbols are supported using APIs:
| Supported Symbols | Example | Description |
|---|---|---|
| .(dot) | entitlement.customer.name=='TestCustomer'
|
Evaluates to true if the name of the customer exactly matches 'TestCustomer'. |
| ' (single quotes) | entitlement.state=='ENABLE'
|
Use single quotes for string values. |
| == | entitlement.state=='ENABLE'
|
Evaluates to true if the entitlement’s state is equal to 'ENABLE'. |
| != | status != 'CLOSE'
|
Evaluates to true if the entitlement’s state is not equal to 'CLOSE'. |
| * (wildcard) | entitlement.customer.*=='TestCustomerExternalid'
|
Evaluates to true if any customer property exactly matches 'TestCustomerExternalid'. |
| () parenthesis | ((entitlement.customer.name == 'TestCustomer' && entitlement.customer.identifier == '1111') || (entitlement.marketGroup.name == 'APAC' && entitlement.state == 'DRAFT'))
|
Evaluates to true if either the customer name must be ‘TestCustomer’ with identifier ‘1111’, or the Market Group is ‘APAC’ and the State is ‘DRAFT’. |
| [*] (array wildcard) | entitlement.productKeys.productKey[*].item.itemProduct.product.nameVersion.name == 'TestProduct'
|
Evaluates to true if at least one product’s nameVersion.name in entitlement.productKeys.productKey matches 'TestProduct'. |
| [1] (indexed array access) | entitlement.productKeys.productKey[1].item.itemProduct.product.nameVersion.name == 'TestProduct'
|
Evaluates to true if the second product’s nameVersion.name in entitlement.productKeys.productKey matches 'TestProduct'. |
Actions for Webhooks
The following table lists the actions available for webhooks:
| Action | Description | |
|---|---|---|
|
|
Edit |
Updates an existing webhook. For details on editing webhooks, see Editing an Entity. |
|
Disable | Prevents the webhook from sending event data to the client application. |
|
Delete |
Deletes a webhook. |