Webhooks

The Webhooks APIs allow external systems to subscribe to events in Inspera Assessment. The webhooks are based on the Event Log system, used by the Inspera Assessment client, but with a limited set of events for which webhooks are currently supported.

General

For both validation and for event notifications, the request sent is an HTTPS POST request, with a default timeout of 10s. If the endpoint does not respond with an HTTP 200 OK the request is considered failed, and retried. For validation requests, we do not retry. For event notifications, we retry 3 times before giving up.

All notifications include a small JSON payload in a fixed format. The payloads include base metadata but do not include extensive data related to the event. This is done to ensure a consistent and controlled payload size. For instance, when subscribing to an event for grading completed the notification does not include any grades, only information about the object for which the event applies. Fetching more detailed information can then be done via the APIs using the identifiers referenced in the webhook payload.

Note that notifications will not be sent out to subscriptions registered on the same user defined as the event's triggering user. This is consistent with how notifications are handled for other notification types in Inspera, and is done to avoid spamming a user with notifications about their own actions in the system.

Verification

In order to verify that an event came from Inspera and is a valid event, a hash of the message body is included in the header of the request. The hash is an HMAC SHA1 Hex of the body using the secret provided when setting up the subscription. The hash is provided in "X-Inspera-Signature".

Webhook APIs

/v1/subscription/events

This API lists all event types for which Webhook subscriptions are supported.

/v1/subscription + /v1/subscription/{subscriptionId}

These APIs allows the caller to list all current subscriptions, and register new ones, as well as delete existing subscriptions. When registering a subscription the provided endpoint is validated, and must respond with a HTTP 200 OK when called with a POST request. The request must respond within the default timeout.

Note that webhook events will only be sent out to users who are both registered listeners of the event and where that same user is either a contributor on the affected test, has write access to the affected content, or is a User Administrator (depending on the object type affected by the event). Users with extended access received all applicable events, regardless of the explicit permissions or contributor roles on individual objects.

The validation request looks something like this:

{
  contextObjectId: 0, 
  contextObjectTitle: d7e7a6dd-1c82-45ff-aea1-cbbbe9ce1bb0, 
  event: verification, 
  timestamp: 2018-10-04T16:44:30Z
}

There is no limited lifetime for subscription to Inspera events. Once a subscription to an event has been made, it does not expire until the user unsubscribes or deletes the subscription. 

It is possible to get the list of events the user is subscribed to by calling the GET method for /v1/subscription endpoint. This method will return array all events user is subscribed to with additional information about each event found.

Format

The payload of every event follows the same general format, with some fields being optional.

Example

{
  "event": "qti_export_ready",
  "marketplaceId": 1357554,
  "contextObjectId": 74379551,
  "contextObjectType": "QUESTION_SET",
  "timestamp": "2021-06-29T18:16:06Z"
}

Extra info

The extraInfo follows a general format, however, the details of the values provided depend on the specific event type.

Auto-unsubscribe

Even if there is a call to unsubscribe to webhook notifications that should no longer be in use, we have experienced that some subscriptions set up for testing are just abandoned when testing is done, leaving the notifications active - also after the endpoint has stopped working.
Since this actually imposes a problem, we have created a feature for automatically unsubscribing ‘dead’ subscriptions.
We will, of course, acknowledge that an endpoint may have temporary issues, and therefore we check several times before actually unsubscribing.
We currently issue a validation-call every 8 hours to each registered endpoint (if two subscriptions use the same endpoint, we only send one message). If an endpoint fails on 3 successive calls, all subscriptions to that endpoint will be automatically unsubscribed - Note this feature is controlled by a configurable setting and has to be turned on to start unsubscribing. If you want this, please contact the Service Desk.