Unable to use $filter with Microsoft Graph Time Card API on our Azure Web App Service

Question

Unable to use $filter with Microsoft Graph Time Card API on our Azure Web App Service

Gaétan 0

We are using an Azure Web App Service to call the Microsoft Graph Time Card Shifts Management API to list all time cards:: https://learn.microsoft.com/en-us/graph/api/schedule-list-timecards?view=graph-rest-1.0&tabs=http .

According to the documentation, this method supports the $filter OData query parameter: "This method supports the $filter OData query parameter to help customize the response".

This is important because, by default, all time cards are returned — potentially thousands of records. In our use case, we only need the shifts/time cards from the last 7 days.

However, when we try a request like:

https://graph.microsoft.com/v1.0/teams/{TEAMID}/schedule/timeCards?$filter=createdDateTime ge 2025-08-10T00:00:00Z

We receive the following error:

"code": "BadRequest",
"message": "The entity property 'createdDateTime' and operationKind 'GreaterThanOrEqual' is not allowed in $filter query."

The same error occurs when attempting to filter by:

lastModifiedDateTime
clockInEvent/dateTime
clockOutEvent/dateTime

It would be surprising if the API always required retrieving all time cards without any date-based filtering.

Our questions:

1. Is this a bug or an intentional limitation?
1. If intentional, why?
1. If intentional, what properties can be used with $filter for this endpoint?
1. If intentional, why is the documentation not mentioning the limitations?

Any guidance or workarounds would be greatly appreciated.

Shree Hima Bindu Maganti 7,585 Reputation points Microsoft External Staff Moderator

2025-08-16T05:01:35.0966667+00:00

Hi @Gaétan
It seems you’re encountering a "BadRequest" error when using the $filter OData query parameter with the Microsoft Graph Time Card API from your Azure Web App Service, particularly when filtering by createdDateTime or similar fields.

Is this a bug or an intentional limitation? According to the documentation and standard industry practices, this is likely an intentional limitation. Some API endpoints do not allow filtering on certain fields.

If intentional, why? API filtering options are often restricted to maintain performance and ensure consistent results. Filtering by properties like createdDateTime may be limited due to potential performance concerns or data structure complexities.

If intentional, what properties can be used with $filter for this endpoint? The documentation for the endpoint should list which properties are supported for filtering. If createdDateTime, lastModifiedDateTime, and clockInEvent/dateTime are not available, you may need to look for alternative properties.

If intentional, why is the documentation not mentioning the limitations? Documentation may not always be fully up to date due to ongoing changes or updates. Providing feedback to Microsoft can help improve the documentation.

As a workaround, you could retrieve all records and apply client-side filtering to get recent time cards, but this may impact performance if the dataset is large.
Let me know if you have any further assistances needed.
Gaétan 0 Reputation points

2025-08-18T01:41:14.47+00:00
Thanks for your response @Shree Hima Bindu Maganti . However, this still leaves a few important gaps unresolved:

The documentation for list timeCards explicitly states:

This method supports the $filter OData query parameter to help customize the response.

If in practice no date-based fields (createdDateTime, lastModifiedDateTime, clockInEvent/dateTime, etc.) are supported, this seems either to be an API error or if this is intentional, then the documentation appears to be incomplete and misleading and should be updated to reflect this.

Could you please confirm (or escalate to the product team to confirm) which properties are actually supported in $filter for this endpoint? Without that, it’s not possible for developers to use the API correctly. If filtering is indeed intentionally limited, then:

Why does the documentation not state this?

Why is $filter mentioned at all if no meaningful fields are supported?

The suggested workaround of downloading all time cards and filtering client-side is problematic. For large organizations this could mean tens of thousands of records per call, which is not scalable and contradicts the point of having OData filtering.

Could you please help clarify this further, or if necessary escalate it through the appropriate support channels, as outlined in the priority community support guidelines?
Raul Fernandes 0 Reputation points Microsoft Employee

2025-09-19T15:24:35.3366667+00:00

Hi @Gaétan,

Thanks for raising this documentation issue. Here are the filter fields and corresponding operations that are supported:

Field Filter operations

Field Filter operations

clockInEvent/datetime ge le

clockOutEvent/datetime ge le

state eq

userId eq

I believe you can use the clock in/out time to filter for the time range you need.

We'll update the documentation. Let us know if you need any additional details.
Gaétan 0 Reputation points

2025-09-23T23:48:53.3466667+00:00

Hi @Raul Fernandes ,

Thank you very much for your reply and announcing to update the documentation. We also really appreciate that filtering by clockInEvent/datetime and clockOutEvent/datetime has now been made available by Microsoft and isn't causing error messages anymore, as I mentioned above and as already raised by others in the past (https://learn.microsoft.com/en-us/answers/questions/1436023/not-possible-to-filter-on-clocked-in-datetime-on-t). This will be a big help!

Your answer

Shree Hima Bindu Maganti 7,585 Reputation points Microsoft External Staff Moderator

2025-08-16T05:01:35.0966667+00:00

Hi @Gaétan
It seems you’re encountering a "BadRequest" error when using the $filter OData query parameter with the Microsoft Graph Time Card API from your Azure Web App Service, particularly when filtering by createdDateTime or similar fields.

Is this a bug or an intentional limitation? According to the documentation and standard industry practices, this is likely an intentional limitation. Some API endpoints do not allow filtering on certain fields.

If intentional, why? API filtering options are often restricted to maintain performance and ensure consistent results. Filtering by properties like createdDateTime may be limited due to potential performance concerns or data structure complexities.

If intentional, what properties can be used with $filter for this endpoint? The documentation for the endpoint should list which properties are supported for filtering. If createdDateTime, lastModifiedDateTime, and clockInEvent/dateTime are not available, you may need to look for alternative properties.

If intentional, why is the documentation not mentioning the limitations? Documentation may not always be fully up to date due to ongoing changes or updates. Providing feedback to Microsoft can help improve the documentation.

As a workaround, you could retrieve all records and apply client-side filtering to get recent time cards, but this may impact performance if the dataset is large.
Let me know if you have any further assistances needed.
Gaétan 0 Reputation points

2025-08-18T01:41:14.47+00:00

Thanks for your response @Shree Hima Bindu Maganti . However, this still leaves a few important gaps unresolved:

The documentation for list timeCards explicitly states:

This method supports the $filter OData query parameter to help customize the response.

If in practice no date-based fields (createdDateTime, lastModifiedDateTime, clockInEvent/dateTime, etc.) are supported, this seems either to be an API error or if this is intentional, then the documentation appears to be incomplete and misleading and should be updated to reflect this.

Could you please confirm (or escalate to the product team to confirm) which properties are actually supported in $filter for this endpoint? Without that, it’s not possible for developers to use the API correctly. If filtering is indeed intentionally limited, then:

Why does the documentation not state this?

Why is $filter mentioned at all if no meaningful fields are supported?

The suggested workaround of downloading all time cards and filtering client-side is problematic. For large organizations this could mean tens of thousands of records per call, which is not scalable and contradicts the point of having OData filtering.

Could you please help clarify this further, or if necessary escalate it through the appropriate support channels, as outlined in the priority community support guidelines?
Raul Fernandes 0 Reputation points Microsoft Employee

2025-09-19T15:24:35.3366667+00:00

Hi @Gaétan,

Thanks for raising this documentation issue. Here are the filter fields and corresponding operations that are supported:

Field Filter operations

Field Filter operations

clockInEvent/datetime ge le

clockOutEvent/datetime ge le

state eq

userId eq

I believe you can use the clock in/out time to filter for the time range you need.

We'll update the documentation. Let us know if you need any additional details.
Gaétan 0 Reputation points

2025-09-23T23:48:53.3466667+00:00

Hi @Raul Fernandes ,

Thank you very much for your reply and announcing to update the documentation. We also really appreciate that filtering by clockInEvent/datetime and clockOutEvent/datetime has now been made available by Microsoft and isn't causing error messages anymore, as I mentioned above and as already raised by others in the past (https://learn.microsoft.com/en-us/answers/questions/1436023/not-possible-to-filter-on-clocked-in-datetime-on-t). This will be a big help!

Field	Filter operations
Field	Filter operations
clockInEvent/datetime	ge le
clockOutEvent/datetime	ge le
state	eq
userId	eq