Presence Object
High-level overview of the presence data model used in Tether API responses and WebSocket events.
Requesting Presence Data
The presence data model is consistent across both WebSocket gateway events and HTTP API responses.
HTTP API
Typically when calling the HTTP API to fetch presence data for users, the response will include presence objects.
GET https://tether.eggwite.moe/v1/presence/{userID}{
success: true,
data: {
// PresenceData
...
}
}WebSocket Gateway
WS ws://tether.eggwite.moe/socket
{
"op": 2,
"d": {
"subscribe_to_ids": ["123456789012345678", "987654321098765432"]
}
}WebSocket Gateway
Check the WebSocket Gateway documentation for details on subscribing to user IDs and receiving presence updates.
When subscribed to user IDs via the WebSocket gateway, presence updates will include presence objects in the d field of PRESENCE_UPDATE and user_id, useful when watching multiple users.
{
"op": 0,
"seq": 123,
"t": "PRESENCE_UPDATE",
"d": {
"user_id": "123456789012345678",
"data": {
// PresenceData
...
}
}Diagram
The diagram represents the relational structure of the typical response presence object returned by the Tether API. More details on the specific fields and properties can be found at Presence Data Model.
Notes on Presence Data
| Field/Property | Description |
|---|---|
| Presence Object | The presence object represents the most recently observed state for a user, as reported by Discord. It may not always reflect the user’s exact real-time presence due to possible delays or missed updates from the Discord gateway |
| spotify | The spotify object is populated when the user is actively listening to Spotify. If null, the gateway does not include Spotify information. |
primary_active_client | The primary_active_client will always be one of the active clients (e.g. desktop, mobile, web, embedded, vr), if present. |
| activities | The activities array may contain custom or third-party activities; its structure may change over time. |