If you build on Meta’s APIs, two completely different things get described as “data access expiring” — and confusing them is how teams lose access to a working integration. One is a per-user, 90-day permission clock. The other is a recurring, app-level assessment that Meta is now consolidating into a single process called data access renewal. They are unrelated, they fail in different ways, and only one of them can deactivate your app.
The two clocks, and why they get mixed up
1. Per-user data access expiration (90 days)
Meta documents that if your app does not use a permission for roughly 90 days — usually because that particular user stopped using your product — the user must re-grant the permission before your app can read their data again. This is silent, it happens per user, and it does not affect your app’s approval status at all. What you see is a slowly shrinking pool of connected accounts and a support queue full of “it just stopped syncing” tickets.
2. Data access renewal (app-level, recurring)
This is an assessment about your app, not about any one user. It is a questionnaire covering how you collect, handle, protect and share Meta platform data. Miss it or answer it badly and the consequence is at the app level — reduced access, or an app that stops serving every one of your customers at once.
What data access renewal actually consolidates
Meta’s responsible platform initiatives historically ran as five separate processes, each with its own trigger, deadline and questionnaire. Data access renewal is Meta’s stated effort to fold most of them into one assessment so an app answers once rather than several times a year.
Data handling questions
Short-form questions about what platform data your app touches and why.
Data Use Checkup
The annual recertification that every live app with advanced access has had to pass. Covered separately in our Data Use Checkup guide.
App Review
The permission-by-permission review with the use case description and screencast.
Data Protection Assessment
The long security and data-sharing questionnaire aimed at apps holding advanced access.
Ongoing reviews
Periodic compliance checks Meta runs against a live app after approval.
Rolling release
Meta has said this arrives in phases, and that an app may receive a renewal dispatch shortly after completing one of the older individual assessments while apps are migrated across.
The practical consequence: during the migration window you cannot assume the assessment you completed last quarter is the one you will be asked for next. An app can legitimately be sitting on a completed Data Use Checkup and still receive a data access renewal dispatch.
The three sections the assessment is built around
- Data handlingWhat Meta platform data your app collects, what each field is used for, and whether any of it is shared with, sold to, or processed by a third party. Every answer here has to match what your product actually does — and what your privacy policy already says in public.
- Data protectionThe security side: how the data is stored, who inside your organisation can reach it, how access is controlled and logged, and what your incident process looks like. This section is where thin answers cost apps the most, because “we use a managed database” is not an answer to a control question.
- Ongoing reviewConfirmation that your live app still matches the use case it was approved for. Products drift — a feature added eighteen months after approval is exactly the kind of thing this section is designed to surface.
Why this is harder than it reads
The questionnaire looks like a form. It is really a consistency audit across four artefacts that most teams have never reconciled with each other: your live product, your privacy policy, your original App Review use case description, and your infrastructure. The assessment does not have to catch a security problem to cost you access — it only has to catch a contradiction.
- Scope drift. The app requests a permission that no current feature uses, or uses data in a way the approved use case never described.
- Privacy policy mismatch. The public policy is generic boilerplate that does not name the Meta data categories the app actually receives, or names ones it does not.
- Vague data-protection answers. Describing intent rather than implemented, demonstrable controls — access restrictions, encryption at rest, retention and deletion.
- Third parties nobody listed. Analytics, error tracking, support tooling and subprocessors that touch platform data and were never disclosed.
- Retention with no end date. Holding platform data indefinitely with no stated deletion trigger or user-initiated deletion path.
- Missed deadline. The dispatch goes to an app contact address nobody monitors, and the first anyone notices is when access is reduced.
What a prepared submission looks like
- A single, current inventory of every Meta permission the app holds, mapped to the specific live feature that consumes it.
- A privacy policy that names the actual data categories and the actual third parties — written to survive being read side by side with the questionnaire.
- Data-protection answers that describe implemented controls in specifics, not intentions.
- A documented retention and deletion path, including the user-facing route.
- Unused permissions removed before the assessment rather than defended during it.
- A monitored contact address on the app, so the dispatch is never the thing that surprises you.
Where this sits alongside your other Meta obligations
Data access renewal does not replace the operational work of keeping an integration alive. Token lifecycle is still a separate problem — see Meta system user access tokens for how SaaS platforms keep server-side access stable without re-authenticating every client. And if your app has not yet cleared the permission tier this assessment assumes, start with what Meta advanced access is and how it is approved.
The realistic view
An app that has been live for a couple of years has almost always drifted from the description it was approved under. That drift is normal engineering, not misconduct — but the assessment reads it as a discrepancy, and reconciling it under a response deadline, with live customers on the platform, is the wrong time to start. The work is preparation: audit the permissions, reconcile the policy, document the controls, and answer from an app that already matches its own paperwork. No specific outcome can be promised on any Meta assessment, but a submission built this way is one that reviewers can verify rather than question.