Your integration can receive a successful Microsoft Graph response and still export only part of the business data. Before trusting a migration file or management report, verify how the application retrieves every page and handles interrupted runs.

A staff directory, customer-facing portal or internal reporting tool may read Microsoft 365 data through Microsoft Graph. If the code treats the first response as the complete collection, a growing organisation can quietly outgrow a once-successful integration. ITZ’s API development and integration service can review completeness, error handling and acceptance tests without treating a partial export as a finished migration.

Ask what “complete” means before testing

Write down the resource, tenant, permissions, filters, selected fields and reporting period. Agree which records should be included and how an independent owner will reconcile them. A directory export limited to active accounts has a different expected result from an all-account inventory. The count on a screen may use different filters from the API request.

Keep this as a business acceptance criterion: “the approved scope is retrieved, reconciled and marked complete only after every required request succeeds.” A green job status or an HTTP success code alone is not that evidence.

Follow the continuation link, not an invented page number

Microsoft’s Graph paging documentation explains that supported collection responses can return @odata.nextLink. The application must follow the entire returned URL until no next link remains. It should not extract a continuation token and construct a different request. Page sizes and supported query options vary by endpoint.

Increasing $top is not a substitute for retrieving subsequent pages. A page can contain zero records and still require continuation. Directory queries that need custom headers, such as ConsistencyLevel, may need those headers explicitly reapplied on later requests. Confirm the endpoint’s documented behaviour rather than assuming all Graph resources paginate identically.

Make interruptions visible to the business

Define distinct run states: started, processing, incomplete, failed and reconciled complete. Store a run identifier, scope, start and finish times, processed counts and the reason for any failure. Keep progress information restricted; do not place access tokens or full personal records in diagnostic logs.

On a recoverable error, preserve enough authorised checkpoint information to resume safely. On an unrecoverable error, leave the export clearly marked incomplete and notify its owner. Do not overwrite the last known-good report with a partial file that looks final. Decide in advance whether a restarted run resumes or starts cleanly, and test that decision with the developer.

Review Your API Export Completeness with ITZ if a report seems smaller than expected. Share the affected resource, expected scope and a redacted error summary, not credentials or customer exports.

Respect throttling instead of racing it

The Graph throttling guidance describes HTTP 429 handling and the Retry-After delay. Immediate repeated requests can prolong the problem. Where that header is absent, Microsoft recommends exponential backoff. Review the SDK’s retry behaviour rather than adding a competing retry loop without understanding it.

A batch response can be successful overall while individual requests inside it are throttled. Check each subresponse; a successful outer status does not establish that every requested item was read. Put a controlled retry policy, operational timeout and incomplete-run alert in the design. The business should know when its report is delayed rather than receiving a silent partial result.

Test the edge cases a small demo misses

  • Multiple pages: use enough approved test records to require continuation and verify the final records are included.
  • Interrupted run: simulate a timeout or throttled response and check the report is not marked complete prematurely.
  • Changed permissions: verify the process exposes missing access rather than hiding it as an empty dataset.
  • Restart: confirm the chosen checkpoint or clean-restart strategy does not silently omit or multiply records.
  • Changing source: agree how changes during the export affect the result and whether the resource supports a suitable change-tracking method.

These are acceptance-test recommendations, not a guarantee that a paged export is a transactionally consistent snapshot. For frequently changing data, use supported delta or change-notification mechanisms where appropriate and document their limitations. Avoid destructive synchronisation based only on an unexpectedly short run.

Separate completeness from other integration risks

The duplicate CRM record guide concerns repeated writes and identity matching. This article concerns missing reads. Both can affect a migration, but they need different tests. The API credential rotation checklist addresses continued access, while software testing can formalise the acceptance checks.

Review Your API Export Completeness. Use the form below to discuss the source endpoint, business scope, pagination, restart behaviour and reconciliation evidence. Request a review of the data path before relying on the export for migration or decisions.

Review Your API Export Completeness ↗

Official Microsoft Graph references reviewed on 14 October 2026. Validate current endpoint behaviour, permissions and SDK support before implementation.