For easy data push integration between Netilion and your application, Netilion provides webhooks. Once configured, a webhook is used to send out notifications to your service.
Once you have configured a URL, Netilion will post the event data as JSON to your webhook URL. You can subscribe to different types of events. Please see the below for all supported types.
When to use webhooks
If your application needs to be automatically informed about changes and new data in Netilion, you can use webhooks. With webhooks you do not need to poll for new data.
Webhooks are asynchronous.
Prerequisites
To receive webhooks, you need an active Netilion Connect subscription with at least one API key. Calls and payload size will be added to the quota usage of the Connect subscription. If the quota is exceeded, the corresponding webhooks will not be called.
Permissions
Webhooks receive events for objects for which the technical user of the Netilion Connect subscription has read permissions.
Handling webhooks
The provided URL must be a publicly accessible https address that handles HTTP POST requests.
Netilion must receive a status code 2XX response from the configured URL to confirm that the notification sent via HTTP POST was successfully delivered. If a webhook times out or returns a different status code, Netilion will retry several times to deliver the event data.
Configure webhooks
To register a webhook, the ID of the client application is required. A client application is generated for each Netilion Connect subscription.
If you do not have the ID, you can get it via the API
With this ID you can register your webhook via
See the API documentation for the request body.
You receive the secret in the response. The secret is needed to validate the payload.
Validating payloads
Clients using the webhooks should ensure that requests are coming from Netilion.
With every incoming POST request from Netilion, a hash signature is passed in the headers. The following hash signatures are available:
HMAC SHA-1 (deprecated, may be removed in future)
Header name: X-Hub-Signature
Value: sha1=XYZ
HMAC SHA-256
Header name: X-Hub-Signature-Sha256
Value: sha256=XYZ
These signatures can be used to validate that the source of the data is Netilion. The hash signature starts with the used hash e.g. sha256=, indicating that the use of HMAC SHA-256 was used for encryption.
The secret used to create the signatures is automatically generated when a new webhook is created and returned in the API call.
It can be changed using the change secret endpoint.
To compute the signature, use the supplied secret as the key and the received payload as the data.
Steps to validate a request
Create a hash using your secret and the incoming payload body.
Compare the generated hash with the signature value provided in the header.
Example code for validation:
Retry handling
As mentioned above, Netilion will retry multiple times to deliver the event data if the request was not successful.
Netilion will attempt to deliver the data 16 times with an exponentially increasing the delay between attempts. The delay time is random. Netilion will retry to deliver the data for approximately 3 days.
After that, it is possible to manually resend the events to the receiver.
Finding the failed events is possible via
More filtering options are available, please see the API documentationfor details.
By sending the event IDs to:
Netilion will restart sending the data (using the retry mechanism described).
After 6 months Netilion will remove the data for the failed events and a re-submission of older events will not be possible.
Enable/disable webhook
Webhook can be enabled or disabled by the user at any time. However, there are cases where Netilion will automatically disable a webhook. For example, if a webhook event for a particular webhook fails repeatedly over a period of more than two weeks, this will unnecessarily consume the connect subscription request quota. In this case, the contact person of the client application that has that webhook will be notified and the user can review the webhook and take action if necessary.
To enable/disable a webhook, the webhook patch request can be used, e.g. in case of enable:
Request body:
Payload & event types
The payload of the webhook contains the event_type and the content, which is different depending on the event type.
The following event types are currently supported:
asset_value_created
Sent, when a new asset value is created. Each value is sent separately in a webhook call. The payload of this event is as follows:
asset_values_created
Is sent whenever new asset values are sent to the Netilion API. Use this webhook if the asset sends multiple values at once, and you prefer to receive them all in one webhook. This webhook sends multiple values grouped by their keys as shown in this example.
Optionally, you can specify the value keys to be sent:
Example request format to retrieve only values with the key pressure or value.
instrumentation_values_created
Is sent whenever new values from an asset with an instrumentation are sent to the Netilion API. You can subscribe to this webhook to receive the values as single values or multiple values. This webhook sends multiple values grouped under their keys if as shown in this example, when the values were created with a single request.
Optionally, you can specify the value keys to be sent:
Example request format to retrieve only values with the key pressure or value.
asset_updated
Is sent when an asset’s parameters are updated. When creating a webhook, add the asset attributes that value updates that you would like to be notified of.
Example request format to receive events when the status or the description of an asset has changed.
The following attributes are supported for the asset_updated event type:
serial_number
description
production_date
last_seen_at
product
parent
tenant
status
If a user doesn’t specify an attribute when subscribing to the webhook, changes to all attributes will be used for notification.
Example payload, when the status has changed:
asset_software_added
Is sent whenever a new software is assigned to an asset.
Payload example:
asset_instrumentation_association_created
Is sent whenever a new association between asset and instrumentation is created.
Payload example:
asset_instrumentation_association_destroyed
Is sent whenever a association between asset and instrumentation is destroyed.
Payload example:
edge_device_updated
This is triggered when an edge device parameter is updated. You can specify the edge device attributes you want to be notified about when setting up a webhook.
Here’s an example of how to format a request to receive notifications when the status or description of an edge device changes:
The supported attributes for the edge_device_updated event type are:
serial_number
description
last_seen_at
tenant
status
type
software_version
If a user doesn’t specify an attribute when subscribing to the webhook, changes to all of the attributes will trigger a notification.
Here is an example payload, when the status has changed:
You can use the status changed webhook to alert users if an edge device’s status is automatically set to offline. To do this, a developer needs to register the following webhook with a technical user:
All technical users who have registered to this webhook and who have read access to the specific edge device will receive a notification.
asset_appeared
Is sent whenever a technical user gets read permission on an asset.
Payload example:
asset_disappeared
Is sent whenever a technical user lost read permission on an asset. It is sent as well for all subordinate child assets.
Payload example:
This event is sent whenever asset is destroyed and technical user with reporting user role subscribed for such webhook event type.
instrumentation_appeared
Is sent whenever a technical user receives read permission on an instrumentation.
Payload example:
instrumentation_disappeared
Is sent whenever a technical user lost read permission on an instrumentation.
Payload example:
node_appeared
Is sent whenever a technical user receives read permission on an node.
Payload example:
node_disappeared
Is sent whenever a technical user lost read permission on an node.
Payload example:
asset_specifications_updated
Is sent when one or more **specifications of an asset are updated, one event is sent per request per webhook, regardless of how many keys have changed in the request. If you want to limit it to a set of keys, you can add the asset_specifications_updated property with the list of keys whose value updates are of interest for notification.
Example request format to retrieve events when the specification my_key1, my_key2, my_key3 of an asset has changed.
If a user doesn’t specify an attribute when subscribing to the webhook, changes to any specification will trigger a notification.
Example payload (if only specifications my_key2, my_key_3 have changed within the request):
event_specifications_updated
Is sent when one or more specifications of an event are updated, one event is sent per request per webhook, regardless of how many keys have changed in the request. If you want to limit it to a set of keys, you can add the event_specifications_updated property with the list of keys whose value updates are of interest for notification.
Example request format to retrieve events when the my_key1, my_key2, my_key3 specification of an event has changed
If a user doesn’t specify an attribute when subscribing to the webhook, changes to any specification will trigger a notification.
Example Payload (if only specifications my_key2, my_key_3 have changed within the request):
event_created
Is sent when an event is created in Netilion (not to be confused with the technical webhook event).
One webhook event is sent per request per webhook. If you want to limit it to a set of event types, you can add the event_created property with the list of event type codes which new events are of interest for notification.
To get event_created events, the technical user of the client application should have at least read permissions on one of the assets or instrumentations specified in the POST call of the events request.
Example request format to retrieve webhook events when events with type codes heartbeat_verification or device_certificate_renewal are created:
If a user doesn’t specify an attribute when subscribing to the webhook, changes to any event creation will trigger a notification.
Example Payload:
event_document_created
Is sent whenever a document is assigned to an event.
Similar to the webhook event_created, a filter based on the event type code can be given to limit the notification to a certain subset of event type codes. Example request:
Payload example:
asset_health_condition_updated
Is sent whenever the health conditions linked to an asset changed.
The webhook payload contains the current status of the asset, the current assigend health conditions and the health conditions assigned before the update.
Payload example:
product_status_changed
Is sent whenever the product status of a product changed if the user has at least one asset that is linked to the product.
The Webhook payload contains the product and status details.
Payload example:
threshold_reached
Is sent whenever a given threshold (high or low) reached for a System, Recipe or Instrumentation if the user has at least one asset linked.
The Webhook payload contains the event type threshold_reached, data, relevant thresholdable type(System/ Recipe/ Instrumentation ) and object details.