Hi, @Sarah Johnson
For secondary statuses, I would first validate the permissions/divisions side.
Custom secondary statuses created under Status Management are presence definitions, so the endpoints I would use to get their IDs are:
- GET /api/v2/presence/definitions
or, if you already have the definition ID:
- GET /api/v2/presence/definitions/{definitionId}
If some secondary statuses are not appearing there, check whether the user or OAuth client calling the API has the required Presence > Presence Definition > View permission and access to the division where those secondary statuses are assigned. Secondary statuses are division-aware, so this can affect what is returned or visible.
For historical data, /api/v2/analytics/users/details/query should be the right place to check the timeline. The secondary status will not usually appear as a separate secondaryStatus field. Instead, it should appear in the primaryPresence array as the organizationPresenceId, while systemPresence still shows the parent primary status, such as BUSY.
So the mapping should be:
primaryPresence[].organizationPresenceId → GET /api/v2/presence/definitions/{definitionId}
If the organizationPresenceId is only resolving to the standard Busy definition and not the custom Busy status, I would test with one agent changing to that exact secondary status during a known interval and query only that user/time range. If the UI timeline shows the secondary status but the API still does not return the expected organizationPresenceId, I would open a Genesys Care case with the user ID, interval, and API response example.
For totals by status, a user aggregate query with tOrganizationPresence may help, but for a detailed timeline I would still start with the user details query.
------------------------------
Arthur Pereira Reinoldes
------------------------------