The Event Object

In this article:

Overview
Attributes
Request headers
Example
Things to keep in mind

Overview

Every SuperPath webhook delivery has the same envelope. SuperPath sends it as the JSON body of an HTTPS POST request to your registered endpoint URL. Your endpoint reads the event attribute to work out what happened, then parses data for that event type.

For how to register an endpoint and handle the request, see Webhooks - Get updates in real-time. For the list of values event can take, see Types of Events.

Attributes

Field	Type	Description
`event`	string	The type of event being sent, for example `user.created` or `points.updated`. See Types of Events for the full list.
`dateSent`	string	An ISO 8601 date-time string, in UTC, of when SuperPath sent the event.
`dateSentOffset`	number	The UTC offset, in hours, of the SuperPath service that sent the event. `dateSent` is already UTC, so you do not need this value to interpret it.
`data`	object	The record the event relates to. Its shape depends on the event — see the Data type column in Types of Events.

These four attributes are the whole body. Whatever the event type, nothing else is sent at the top level.

Every data object, for every event type, includes at least these two fields:

Field	Type	Description
`tenantId`	string	The ID of your SuperPath account.
`id`	string	The ID of the record the event relates to.

Request headers

Header	Sent	Description
`Content-Type`	Always	`application/json` — the body is JSON.
`SuperPath-Signature`	Only when signature authentication is on for that webhook	`<timestamp>,<signature>`. See Webhook Signature Authentication.

SuperPath does not send an API key, bearer token or any other credential to your endpoint, so your endpoint must accept unauthenticated POST requests. Signature authentication is the mechanism for verifying the sender.

Example

A user.created delivery:

{
  "event": "user.created",
  "dateSent": "2022-02-15T10:36:36.300Z",
  "dateSentOffset": 0,
  "data": {
    "tenantId": "abcdef",
    "id": "foettyQz714xBVi75gZ6",
    "firstName": "John",
    "lastName": "Lennon",
    "email": "john@beatles.com",
    "position": "Founder & CEO",
    "roleId": "admin",
    "roleName": "Admin",
    "avatar": "https://res.cloudinary.com/superpath/image/upload/23423234234/john.jpg",
    "username": "john.lennon",
    "employeeId": "2123234",
    "timezone": "Australia/Sydney",
    "pointsTotal": 427,
    "pointsSelfAssigned": 336,
    "pointsAssigned": 0,
    "status": "active",
    "isDeleted": false,
    "dateCreated": "2020-11-13T11:48:42.109Z",
    "dateCreatedOffset": 11,
    "dateLastModified": "2022-02-15T10:36:21.354Z",
    "dateLastModifiedOffset": 11,
    "userFullNameLastModified": "Jake Jackson",
    "userIdLastModified": "foettyQz714xBVi75gZ6"
  }
}

Things to keep in mind

Read the event attribute rather than inferring the event from the shape of data — several events share the same data shape, for example user.created, user.updated and user.deleted.
Handle event names you do not recognise gracefully. New event types are added over time, so do not assume that only the events documented today will ever arrive.
Treat data as additive. Fields may be added to a payload over time, so parse the fields you need rather than rejecting a payload with unfamiliar fields in it.
Do not rely on the order of keys in the JSON body.
On a delete event, data carries the record as it was immediately before it was deleted, so you still have the id and the details you need to reconcile your own copy.

Updated on: 25/07/2026

Was this article helpful?

Thank you!