The webhook service allows you to register public callback URL's of your own application which should be called when a certain event happens (this mechanism is called a webhook, hence the name of the service). The event type that triggered a webhook call is provided in the X-Innius-Event request header.
The webhooks are registered either on a company level or on a machine level. Registering webhooks to machines that have been shared with your company can only be done on machine level.
Optionally an event can be verified by checking the X-innius-validation header. In the response to the webhook request a base64 encoded PKIX marshalled RSA(PSS)-SHA256 public key is provided. Each event will have the X-innius-validation header which contains a base64 encoded version of the message body after it has been encrypted with our private key. To verify that the event was sent by innius the header can be decoded and checked against the message body. If they are identical the message is valid.
Events:
The currently supported events are:
- SensorStateChange
- MachineStateChange
- SensorCreated
- SensorDeleted
- TaskCreated
- TaskStatusChange
- TaskAssigneeChanged
The body of the webhook call will contain JSON data dependent on the event type and the event type itself will be in the X-Innius-Event header. The bodies are as follows:
SensorStateChange:
{
"sensorid": string
"machinetrn": string
"conversationid": string
"status": integer (0 = Normal, 1 = Caution, 2 = Emergency)
"previousValue": double/float
"currentValue": double/float
}
MachineStateChange:
{
"sensorid": string
"machinetrn": string
"conversationid": string
"status": integer (0 = Normal, 1 = Caution, 2 = Emergency)
}
SensorCreated:
{
"sensorid": string
"machinetrn": string
}
SensorDeleted:
{
"sensorid": string
"machinetrn": string
}
TaskCreated:
{
"machinetrn": string
"activity_id": string
"activity_type": string
"scheduled_start": integer (milliseconds since unix epoch)
"scheduled_end": integer (milliseconds since unix epoch)
"assignee": string
"title": string
"conversation_id": string
"description": string
}
TaskStatusChange:
{
"machinetrn": string
"activity_id": string
"title": string
"conversation_id": string
"status": integer (where 1,2,3,4 and 5 denote ToDo, In Progress, Done, Cancelled and Postponed respectively)
}
TaskAssigneeChanged:
{
"machinetrn": string
"activity_id": string
"title": string
"conversation_id": string
"assignee": string (a trn)
}
Example:
In this example we create a basic web server using node.js + typescript and register a webhook to the TaskCreated and TaskStatusChange events. When these webhooks are triggered a message will be logged to the console. To handle the asynchronous aspects of http calls we use Rxjs.
First off we build our server. This will be a basic express server with a router registered to it on the /activities path. We run this on localhost and then create a tunnel via ngrok to create public endpoints that innius can use for the callbacks.
As you can see we've split the project into three files. The first, server.ts, sets up the server and registers the webhooks. triggers.ts creates the activities to verify that our demo works and receivers.ts contains the handlers logic. receivers.ts is a pretty short file as all we're doing is logging to the console.
The webhooks are then registered by running a scenario from within server.ts
Where RegisterWebhooks and unregisterWebhooks are given by:
and triggers.playScenario is
This scenario is just an automated form of what happens when you create or update an activity manually from the website. It is included in this example for the sake of completion but in principle all you need is the server, the handlers and the webhook registrations. The create/updateActivity functions are:
