Delta query returns @odata.nextLink: false and @odata.deltaLink: false instead of valid URLs despite remaining items

Question

Environment:

• API Endpoint: https://graph.microsoft.com/v1.0/sites/{site-id}/drives/{drive-id}/root/delta

Problem Details:

When executing a delta query against a SharePoint drive using a delta token,

the API returns :

{

**"@odata.nextLink": false,**

**"@odata.deltaLink": false,**

"value": [...]
```  }  
  
**This is weird as there are more items still present in my site**

Answer 1

Hi Tharun test user

Thank you for reaching out to Microsoft Q&A forum

Based on your description, I understand that when you run a Microsoft Graph delta query against a SharePoint drive using a delta token, the API response shows @odata.nextLink: false and @odata.deltaLink: false, even though there are still items in the site. This seems incorrect because these properties should normally contain URLs for paging or delta tracking.

As far as I know, Microsoft Graph does not return false for @odata.nextLink or @odata.deltaLink. These fields are either present as opaque string URLs or absent. That said if you see false, it usually means the client code or SDK is coercing missing properties into boolean values during logging or serialization.

The correct behavior is: intermediate pages include @odata.nextLink, the final page includes @odata.deltaLink, and if there are no changes, you still get a @odata.deltaLink with an empty value array. Missing tokens, skipped pages, or incorrect deserialization often cause incomplete results and confusion.

However, based on the current information you’ve provided, I’m unable to give a precise diagnosis of the issue. So, to better identify the root cause, could you please share some additional details as outlined below? 

1. Do we receive a @odata.deltaLink string on the final page of the initial /delta run, and are we persisting and reusing that exact opaque URL without changes?
2. Are @odata.nextLink and @odata.deltaLink treated as nullable strings in our code, or are we coercing missing properties to booleans (e.g., || false)?
3. When calling the persisted @odata.deltaLink, do we paginate through any @odata.nextLink responses until a new @odata.deltaLink appears, and do we persist that new one?
4. Are we accidentally using a $skiptoken link instead of a $deltatoken link for subsequent syncs?
5. Have we verified the raw Graph response (e.g., via Graph Explorer) to confirm whether the service returns these properties correctly before client-side processing?

In the meantime, you may try the following workaround methods to see if they help resolve the issue:

1. Start with GET /sites/{site-id}/drives/{drive-id}/root/delta.
2. Follow every @odata.nextLink until you reach a page with @odata.deltaLink.
3. Persist the exact @odata.deltaLink for future incremental syncs.
4. On subsequent runs, call the persisted delta link without modification and repeat the paging loop.

I am looking forward to hearing from you to better support, thank you for your patience