Microsoft Graph API for Users delta is only returning 200 or fewer records. Is there any way to get more records in a a single API call?

Question

Microsoft Graph API for Users delta is only returning 200 or fewer records. Is there any way to get more records in a a single API call?

Kumar Sugandh 45

Hi,

We are currently calling the Microsoft Users delta API to retrieve user updates for a specific tenant. We've observed that each API call returns 200 or fewer records, along with a @odata.nextLink if more events are available.

Although we continuously call the API using the next link, it consistently returns 200 or fewer records. We have a few questions regarding this behaviour:

Is there a way to increase the number of records returned by the Microsoft Users delta API per call?
Since the returned records may contain updates for users we have already pulled, is there a recommended approach to fetch all available users initially and then switch to using the delta functionality?
When the delta API is called without any delta link (to initiate user tracking), how does the Microsoft API determine the starting point for returning data?

Any guidance on these issues would be greatly appreciated. Thank you!

0 comments

2 answers

Your answer

Answer 1

Rukmini 39,110 Microsoft External Staff Moderator

Hello Kumar Sugandh

During the initial snapshot, unique users per page are not guaranteed by the Microsoft Graph /users/delta endpoint. The same user may appear on several pages because the snapshot is created while the directory's contents is still changing (for instance, if the object is modified while paging is underway).

Forcing different users on each page is not a server-side option. The suggested and supported method is to use processing to handle this on the client side:

Keep a user-id-keyed local store.
Instead of presuming uniqueness, perform upsert (insert/update).
If necessary, overwrite existing entries and handle duplicate records as usual.

You can also utilize a standard /users API query (non-delta) to retrieve the entire dataset first, and then switch to delta queries for tracking changes moving forward, if your goal is to tightly avoid duplicates during the initial load.

Let me know if any further queries - feel free to reach out!

Rukmini 39,110 Reputation points Microsoft External Staff Moderator

2026-04-29T07:56:26.93+00:00

Hello Kumar Sugandh

When using Microsoft Graph's Users delta API, this behavior is expected. Even with query parameters, the service controls the page size, which is normally limited to about 200 objects. To ensure that you retrieve the entire dataset, the proper method is to follow the @odata.nextLink until it stops.

To get a complete snapshot for the initial sync, you should run the delta query without a deltaLink and page through all of the results. Use the returned @odata.deltaLink for incremental modifications only after that. When the API is started without a deltaLink, it returns a snapshot of the users' current state at that moment. After it is finished, it offers a deltaLink to effectively track changes in the future.

Let me know if any further queries - feel free to reach out!
Kumar Sugandh 45 Reputation points

2026-04-29T10:38:03.5266667+00:00

Hi Rukmini,

Thanks for your quick response.

This is what we have even implemented, and currently we are facing issue with the initial sync (i.e. user delta API call without delta link). It is observed that most of the API calls (with next link) are returning the same exact response or list of users which are already returned in earlier API calls. Only few users are new in the response or have minor updates.

Could you please help us know if there is any thing we can do to get the distinct users in the initial sync (i.e. user delta API call without delta link)?
Rukmini 39,110 Reputation points Microsoft External Staff Moderator

2026-05-01T03:31:27.1+00:00

Hello Kumar Sugandh

Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Kumar Sugandh 45 Reputation points

2026-05-05T12:07:02.5933333+00:00
Hi Rukmini,

Thank you for your support.

I need a confirmation of my understanding regarding the approach that you suggested to avoid duplicates in initial sync. You suggested to use a standard /users API query (non-delta) to retrieve the entire dataset first, and then switch to delta queries for tracking changes moving forward.

My understanding of the specific implementation logic is as follows:

First call the User delta API (using $deltatoken=latest) and store the response delta link.

Immediately start the initial sync using the standard User API.

Once the initial sync is completed, use the delta link (stored in #1) to fetch the changes/updates on the user collection. Is this correct?
Rukmini 39,110 Reputation points Microsoft External Staff Moderator

2026-05-05T13:13:20.4266667+00:00
Hello Kumar Sugandh

All current users will be ignored if /users/delta?$deltatoken=latest is called prior to the initial full sync; only modifications will be tracked after that. This implies that users established or updated before to that time will be missed.

Initial full load -> Call the \users endpoint with non delta and retrieve all users.

Start delta tracking -> Call /users/delta (without any token) and Page through all results until you receive the final @odata.deltaLink

From the step 2 use the @odata.deltaLink from step 2 to fetch incremental changes

Let me know if any further queries - feel free to reach out!
Kumar Sugandh 45 Reputation points

2026-05-06T05:36:19.08+00:00

Hi Rukmini,

We have observed that delta tracking using /users/delta (without a token) takes a very long time to fetch data. We are receiving too many duplicate responses, which means we can only fetch approximately 200 users' information every 5 minutes. This is causing the pull process to run for days.

Instead of making that call, we thought getting the delta link by calling /users/delta?$deltatoken=latest.We assume this will provide us with a cursor to track new changes from that point in time. We would then immediately initiate the initial full load (using the \users endpoint). Once the full load is complete, we can fetch all subsequent updates using the delta link. We believe this approach will ensure we don't miss any updates.

Could you please share your thoughts on why you believe we might miss data with this approach?

Answer 2

The page size (for example, ~200 users) in Microsoft Graph delta queries is controlled by the service and cannot be arbitrarily increased. The service returns a collection plus an @odata.nextLink when more data is available, and clients are expected to follow that link until an @odata.deltaLink is returned. For users, the pattern is:
- Initial call: GET https://graph.microsoft.com/v1.0/users/delta
- If the response has @odata.nextLink, call that URL repeatedly until the response contains @odata.deltaLink.
- A page cannot contain both @odata.nextLink and @odata.deltaLink.
This behavior is by design; there is no documented way in the provided context to increase the maximum number of users returned per page.
The recommended approach is exactly what is described for delta queries:
- First, perform a full synchronization by calling the delta function without a delta token and then following @odata.nextLink until an @odata.deltaLink is returned. That initial round returns the users that currently exist in the collection and represents the full state at that time.
- Persist the final @odata.deltaLink.
- For subsequent syncs, call the saved @odata.deltaLink to get only changes (additions, deletions, or updates) since the last round. If there are changes, the response includes changed user objects and either another @odata.nextLink (more pages of changes) or a new @odata.deltaLink.
The documentation explicitly states that when there are no changes, a @odata.deltaLink is returned with an empty value array; when there are changes, the response includes the changed user objects plus either @odata.nextLink or @odata.deltaLink. The client should always follow @odata.nextLink and persist the final @odata.deltaLink for future calls.
When the delta API is called without any delta token (no @odata.deltaLink or $deltatoken), that call represents the initial synchronization request. For directory objects such as users:
- The initial delta query returns the resources that currently exist in the collection at the time of the request. Deleted objects from before that initial query are not returned, and prior updates are reflected only as the latest state of each resource.
- The service then uses state tokens ($skipToken in @odata.nextLink, $deltatoken in @odata.deltaLink) to encode the state of the collection from that starting point forward. These tokens are opaque to the client; the client simply reuses the URLs returned.
Additionally, for Microsoft Entra ID resources such as users, a “sync from now” scenario is supported: instead of doing a full initial read, a client can request the latest @odata.deltaLink by appending $deltatoken=latest to the delta function. In that case, the response contains only a @odata.deltaLink and no resource data, and subsequent calls using that @odata.deltaLink will return changes from that point forward. Note that delta tokens for directory objects are only valid for seven days; after that, a full synchronization must be performed again.

References:

Share via

Microsoft Graph API for Users delta is only returning 200 or fewer records. Is there any way to get more records in a a single API call?

2 answers

Your answer