Event Structure
All our webhook events have the following standard structure:
- A top-level
event_type
field, specifying the payload type contained in thedata
field. - A top-level
data
field containing the event-specific payload. - A set of top-level fields describing the event subject:
team_id
: Your Vital Team ID.user_id
andclient_user_id
: The unique Vital User ID.client_user_id
: Your application user reference you declared for the Vital User.
Schemas and examples are available through the Event Catalog tab in the Webhooks section of our Web app.
Wearable data events
Wearable data events have the following extended standard structure:
- An
event_type
field for differentiating the payload contained in the data field. - A
data
field, which comprises of:- The UUID of the Vital user for which this event is intended — note that this is not the
client_user_id
of the Vital user. (JSON path:$.data.user_id
) - The metadata about the data source of this event (JSON path:
$.data.source
)name
: The human-readable name of the sourceslug
: The stable identifier Vital assigned to the source — see Supported providers for the complete list.logo
: The URL to an icon representing the source.
- Any number of event-specific fields.
- The UUID of the Vital user for which this event is intended — note that this is not the
Summary types
Each time a summary object is created or updated, Vital emits a data event for the occurrence.
The object is made available directly at the top-level data
field (JSON path: $.data
), alongside the standard fields listed above.
Each summary is uniquely identified by its ID ($.id
).
Given the same ID, the latest version of a summary you received replaces all its previous versions.
Timeseries types (except for Workout Streams)
Each time a batch of timeseries samples has been created or updated, Vital emits a data event for the batch of samples.
The samples are made available under an inner data
field under the top-level data
field (JSON path: $.data.data
).
Each timeseries sample is uniquely identified by a compound key of:
- the timeseries resource type;
- the source provider;
- the Source Type; and
- the sample timestamp.
Given the same compound key, the latest value of a sample you received replaces all the previous values.
These exceptions are the rationale behind the recommended deduplication semantic as stated above.
Workout Streams
While Workout Streams are classified as a timeseries type, it contains a huge amount of timeseries data which cannot be delivered by our webhook message transport.
So events for Webhook Streams are shallow, with only some minimal metadata about the workout. Successful
reception of the event indicates that the data are available to be read via our REST API,
e.g., the Workout Stream endpoint GET /v2/timeseries/workouts/{workout_id}/stream
.