> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://help.superpath.io/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# The Event Object

# 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](https://help.superpath.io/en/article/webhooks-get-updates-in-real-time-19fivqo/). For the list of values `event` can take, see [Types of Events](https://help.superpath.io/en/article/types-of-events-1vqpo0f/).

## Attributes

| Field | Type | Description |
|---|---|---|
| `event` | string | The type of event being sent, for example `user.created` or `points.updated`. See [Types of Events](https://help.superpath.io/en/article/types-of-events-1vqpo0f/) 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](https://help.superpath.io/en/article/types-of-events-1vqpo0f/). |

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. |
| `User-Agent` | Always | `SuperPath-Webhooks/1.0`. |
| `SuperPath-Delivery-Id` | Always | One id per event per webhook, the same on every retry of that delivery. Use it to skip a delivery you have already processed. |
| `SuperPath-Attempt` | Always | Which attempt this is, from `1` to `6`. A failed delivery is retried for about 8.5 hours; see [Webhooks - Get updates in real-time](https://help.superpath.io/en/article/webhooks-get-updates-in-real-time-19fivqo/). |
| `SuperPath-Signature` | Only when signature authentication is on for that webhook | `<timestamp>,<signature>`. See [Webhook Signature Authentication](https://help.superpath.io/en/article/webhook-signature-authentication-1toumv3/). |

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:

```json
{
  "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.