Meta App Review: privacy and deletion

What reviewers check

1. Reviewer access

   Reviewers must reach the app and exercise the functionality behind each requested permission.

   Official source: Meta: App Review testing

2. App identity and public links

   Basic Settings includes your privacy policy, terms and contact details. Keep them accurate and relevant to this app.

   Official source: Meta: Basic Settings — policy URLs

3. A real deletion route

   Explain how people request deletion. If using a callback, implement deletion and return a status URL and confirmation code.

   Official source: Meta: Implementing the Callback

Documented rejection risks

1. An inaccessible app

   Meta explicitly says an app it cannot access for testing will have its submission rejected.

   Official source: Meta: App Review testing

2. An untestable permission

   If reviewers cannot test a requested permission’s functionality, that permission will not be approved. This is not a frequency ranking.

   Official source: Meta: App Review testing

3. A callback that does not delete

   A callback must do more than display instructions. Noncompliance can lead to its removal or the app being disabled.

   Official source: Meta: Implementing the Callback

Submission checklist

1. Identify the audience

   Write down who will use the submitted app: only people with app or owning-business roles, or people outside those roles. Compare that audience with Meta’s overview before preparing the submission. Record the requested permissions separately; role-only testing does not demonstrate that general-user access has been approved.

   Official source: Meta: App Review audience

2. Map permissions to working features

   Create a reviewer instruction sheet with the starting URL, access instructions and numbered actions for each requested permission. Name the visible result that demonstrates the feature. Rehearse the sheet with the same access you will provide, checking that missing privileges or unavailable test data do not stop the reviewer.

   Official source: Meta: App Review testing

3. Configure policy links

   Open the app’s Basic Settings and enter the real Privacy Policy URL and Terms of Service URL. Confirm that each page belongs to this app and describes its actual service. As a preparation check, open the links in a signed-out browser and remove placeholders or broken destinations before submission.

   Official source: Meta: Basic Settings — policy URLs

4. Explain deletion requests

   Choose a public page that explicitly explains how users request deletion and configure its address in the deletion-instructions field. It can be a relevant section of the privacy policy. Test the described route yourself and check that a person can understand what to submit and what happens next.

   Official source: Meta: Basic Settings — deletion

5. Implement the callback if chosen

   If choosing the callback route, configure an HTTPS endpoint and implement handling of Meta’s signed request. The endpoint must initiate deletion and return a URL for checking status plus an alphanumeric confirmation code. Connect that response to the real deletion workflow; publishing instructions or returning a sample JSON object does not implement it.

   Official source: Meta: Implementing the Callback

6. Test the deletion path

   Use a test account to log in through Facebook, then follow Meta’s Apps and Websites procedure to remove the app and send a deletion request. Check that your endpoint receives it and that the returned status page reflects the actual result. Keep synthetic test evidence for your implementation review, not real user data.

   Official source: Meta: Testing Your Callback

Example

1. Fictional app: Harbor Events

   Fictional input: Harbor Events has one implemented Meta integration, a synthetic event called Harbor Demo, and a dedicated reviewer account. Assume the requested permission is necessary for that implemented feature; its real name must come from the app’s actual integration. The owner writes: open the supplied URL, sign in with the supplied test access, choose Harbor Demo, invoke the integration and inspect the resulting event. Expected artifact: a reviewer sheet connecting one permission to one repeatable action and visible result, without exposing real customer data.

   Official source: Meta: App Review testing

2. Fictional submission URLs

   Fictional input: the app’s public domain is harbor.example and its owner has drafted three pages. The owner enters https://harbor.example/privacy and https://harbor.example/terms in Basic Settings, then opens both without signing in. The privacy page identifies Harbor Events and links to https://harbor.example/delete-data, which explains the chosen request route. Expected artifact: a checked URL inventory with the purpose of each page and any remaining implementation gaps. These reserved example addresses are placeholders, not working pages or evidence that Meta has approved an app.

   Official source: Meta: Basic Settings — policy URLs

3. Trace one test request

   Fictional input: Harbor Events chooses a callback and holds only synthetic data for test user T1. Its implementation validates the incoming request, creates deletion job REVIEW01 and returns a status URL plus the confirmation code REVIEW01. The example status page first says the request is pending. After the worker actually removes the test data, the page reports completion. Expected artifact: a trace linking request, job, deletion result and status page. This lifecycle is an illustrative design; returning the code without deleting data would not satisfy the callback requirement.

   Official source: Meta: Implementing the Callback

https://harbor.example/privacy
https://harbor.example/terms
https://harbor.example/delete-data

Frequently asked questions

1. Is a static deletion page a callback?

   No. It can explain instructions; a callback must receive and process requests and initiate deletion.

   Official source: Meta: Implementing the Callback

2. Does role-only use require App Review?

   The overview exempts use limited to app roles. Check your app’s actual audience and permission requirements before relying on that condition.

   Official source: Meta: App Review audience

3. What does the callback return?

   A URL where the person can check deletion status and an alphanumeric confirmation code, alongside initiating the deletion.

   Official source: Meta: Implementing the Callback