I don't know exactly what you are trying to accomplish, but I do have a bit of a warning about the 30 minute granularity approach. Making multiple historical adherence requests, each with a range of only 30 minutes, could quickly run into rate limiting, if the total range of data you require is large. It technically could work but could be very slow to make all the requests.

Thank you @Dan_Hoffman
Currently we are going with your suggestions by using customer specific Timezone instead of UTC. Will revisit this again to support multiple timezones by saving data with Granularity PT30M and UTC Timezone.

So all data is returned in UTC regardless of the time zone parameter. The time zone parameter only changes what is considered the start of the day for the day metrics but it will still be returned in UTC.

Here is how I would recommend using the bulk historical adherence endpoint. You should make sure in the request that all the management units you request have the same time zone configured, and set that as the time zone parameter. Also make sure that the startDate and endDate you provide are set to the start of day for that time zone. For example if I wanted to request yesterday's adherence for two management units in the same business unit, and that business unit was configured for the America/New_York time zone, the request body would look like this:

{
    "timezone": "America/New_York",
    "items": [
        {
            "managementUnitId": "someId",
            "startDate": "2024-11-11T05:00:00Z",
            "endDate":  "2024-11-12T05:00:00Z",
            "includeExceptions": true,
            "includeActuals": true
        },
        {
            "managementUnitId": "someOtherId",
            "startDate": "2024-11-11T05:00:00Z",
            "endDate":  "2024-11-12T05:00:00Z",
            "includeExceptions": true,
            "includeActuals": true
        }
    ]
}

This will return adherence for November 11th for those management units. Since the start of day for the America/New_York timezone for that day is 2024-11-11T05:00:00Z, there will only be a single day metric that is lined up perfectly with the requested date range.

If we aim to support multiple time zones and there isn't a granularity property like PT30M available in the request body, we need to consider how to structure our queries. For instance, if we want to retrieve adherence data for the past day in UTC, should we break the request interval into 30-minute segments?

The formula used to calculate adherence and conformance percentages can be found here:

In the web API response data, which fields/properties are being used to calculate:

1. The adherence percentage
2. The conformance percentage?"

This would help identify the specific data fields from the API response that are being used in these calculations.

In an Old genesys forum discussion, it was explained that the start date of the day is calculated by adding dayStartOffsetSeconds to startDate from the dayMetrics data. Following this same logic, how would we calculate or determine the end date of the day?