Home › Resources

Facebook Privacy Policy: What to Disclose for Apps, Ads, and Pages

Updated October 20, 2026

Meta requires a privacy policy URL in three distinct places: the Privacy Policy URL field under App settings > Basic in the App Dashboard, the Link URL field in the Privacy section of every Lead Ads instant form, and the Page Settings > Page Info section for Facebook Pages that collect visitor data. Only the first two block you: an app cannot switch to Live mode, and an instant form cannot be published, while the field is empty.

This guide covers where Meta asks for the URL across apps, ads, and Pages, what Facebook's Platform Terms and Business Tools Terms require your policy to disclose, the data each Graph API permission returns, the privacy policy field inside Lead Ads instant forms, the disclosure obligations that come with Meta Pixel and the Conversions API, and common reasons App Review rejects a privacy policy. If you need a finished policy without writing one from scratch, generate a free privacy policy and get a hosted URL you can paste into your App Dashboard or Lead Ads form.

Where Meta Asks for a Privacy Policy URL

Inside the App Dashboard you enter the URL once; three later checkpoints re-read it.

• App settings > Basic. Two fields matter here. Privacy Policy URL sits below App Domains, beside Terms of Service URL; Platform Terms clause 4.a requires your policy URL to be disclosed in this field. Directly beneath it, User data deletion takes either a Data Deletion Instructions URL (a page telling users how to request deletion) or a Data Deletion Callback URL (an endpoint Meta calls when a user removes your app). Leave the privacy field blank and the Development-to-Live toggle refuses to switch, with an error pointing back to this page. Run the URL through the Sharing Debugger first: anything other than a 200 response code fails review.
• App Review submission. When you submit permissions or features for App Review at App Dashboard > App Review > Permissions and Features, Meta's review team visits your privacy policy URL as part of their evaluation. The review checks that the policy matches the data your app actually accesses through the permissions you requested. A policy that does not mention the specific permissions under review will be rejected.
• Business Verification. Apps requesting advanced access to certain permissions must complete Business Verification through the App Dashboard > Settings > Advanced > Business Verification section. The verification process requires a legal entity with a privacy policy URL that matches the business identity. The policy must be hosted on a domain the business controls or on a verified website.
• Data Use Checkup. Meta periodically requires apps to complete a Data Use Checkup through a banner notification in the App Dashboard. The checkup asks developers to re-confirm how they use each approved permission and verifies that the privacy policy URL is still active. Apps that fail the checkup or let it expire have their permissions revoked.

What Meta's Platform Terms Require the Policy to Disclose

Section 4 of Meta's Platform Terms is titled "Privacy Policy." Clause 4.a makes the URL mandatory: "You will provide, maintain, and comply with a privacy policy that is available through an active, publicly available, easily accessible (including by our crawlers), and non-geoblocked URL. This URL must also be disclosed in the privacy policy field in the settings of your App Dashboard." Clause 4.b sets the content: the policy "must clearly explain what data you are Processing, how you are Processing it, the purposes for which you are Processing it, and how Users may request deletion of that data." Meta's Privacy Policy Expectations page adds that it "must be your own privacy policy, and not the policy of another company."

The policy must disclose:

• What data is collected. Every category of information your app collects from or about users, whether obtained directly through Facebook's APIs, through third-party SDKs, or gathered independently (browser information, IP addresses, device identifiers, server logs). If your app requests the email permission, your policy must state that you collect email addresses from Facebook. If you request user_birthday, you must disclose that you collect date of birth.
• How the data is used. Each specific purpose for processing the data. Meta expects concrete descriptions -- "to personalize content recommendations," "to send weekly summary emails," "to match users with relevant groups" -- not vague catch-alls like "to improve our services." The purpose must match what you described in your App Review submission.
• How users can request deletion. A working method for users to request that their data be deleted. This can be an email address, a contact form, or, for apps that support it, Meta's Data Deletion Request Callback. The URL or contact method you provide must be active and monitored -- Meta's review team tests it. If your app implements the Data Deletion Callback, enter it under App settings > Basic > User data deletion as a callback URL or a data deletion instructions URL.
• Third-party sharing. Whether data obtained through Facebook's APIs is shared with any third party, and if so, which parties and for what purposes. Meta's Platform Terms prohibit transferring data received through their APIs to any data broker, ad network, or data reseller, even if your policy discloses it.
• Data retention. How long you keep data obtained through the APIs. Platform Terms clause 3.d requires deletion when a user asks, when they no longer have an account with you, and when you stop operating the product that collected the data. Meta signals app removals to the Deauthorize Callback URL set under Facebook Login settings.

Clause 4.c then limits you to processing Platform Data "as clearly described in your privacy policy," so data missing from the list above is data you may not use. Writing a complete privacy policy for any app starts with auditing which data your app actually touches.

Facebook Login and Graph API Permissions: Data Each Returns

Only public_profile is granted automatically. user_photos, the pages_* permissions, read_insights, and ads_management need Advanced Access through App Review before they work for people without a role on your app, and the reviewer checks your policy against the list at App Review > Permissions and Features.

What each permission obliges the policy to say: for public_profile, that you store the app-scoped user ID, name, and profile picture; for email, that you receive the account's primary email and what you send to it; for user_photos, which photos you read, whether you copy them to your own storage, and for how long; for pages_show_list, that you read the Pages a person manages (Meta's submission form asks for "specific examples of why your app needs to access the list of pages that a user owns"); for ads_management, that you read and change ad accounts on the user's behalf, which also requires Business Verification. A permission with no matching feature in your screencast is rejected even when the policy covers it. Generate the data-collection disclosures for any third-party SDKs your app bundles with the SDK disclosure generator.

Facebook Pages and Lead Ads Privacy Requirements

Neither surface below goes through App Review; Ads Manager and Page settings enforce them instead.

• Facebook Pages. Any Page that collects information from visitors -- through messaging, Lead Ads, or Shop features -- must link to a privacy policy. For Pages managed through a third-party app, the app's privacy policy must also disclose that it accesses Page data. The pages_read_engagement scope gives access to follower PSIDs (Page-Scoped User IDs) and profile pictures, which are personal data under GDPR even though they differ from the user's global Facebook ID.
• Lead Ads. Every instant form needs a policy URL before it publishes, and the policy must name each field the form collects. The form builder steps are in the next section.
• Custom Audiences. If your app uploads customer lists to create Custom Audiences (via ads_management or the Marketing API), your privacy policy must disclose that you share user data with Meta for advertising purposes. This includes hashed email addresses, phone numbers, and any other identifiers used for matching.

Privacy Policy URL in Meta Lead Ads Instant Forms

Every Lead Ad campaign in Meta Ads Manager requires an instant form, and every instant form requires a privacy policy URL before it can be published. This requirement applies to anyone running lead generation ads on Facebook or Instagram -- you do not need a Facebook app or App Review to encounter it.

Where the field sits in Ads Manager

In Meta Ads Manager, choose the Leads objective, set the ad set's conversion location to Instant forms, then click Create form at the ad level. The editor runs in this order: Form type, Intro, Questions, Privacy, Message for leads. The Privacy section holds two required fields, Link text (the words shown on the form) and Link URL (your policy), plus an optional custom disclaimer for consent wording such as a marketing opt-in. The form will not publish until Link URL holds an HTTPS address. On the rendered form the link appears on the final review screen, next to Meta's notice that the info is sent to your business, before the user taps Submit.

What Meta rejects

Meta validates the privacy policy URL when you save the instant form. The URL must return an HTTP 200 response over HTTPS. A URL that redirects through a login wall, returns a 404, points to localhost, or loads a page that is not recognizably a privacy policy will cause the form to fail validation. Meta's Lead Ads Terms require that the linked policy be your own (not a third party's boilerplate) and that it accurately describe how you handle the data collected through the form.

What the policy must disclose about lead data

The instant form collects exactly the fields you configure: standard fields such as Full Name, Email Address, Phone Number, Job Title, Company Name, and Work Email, plus any Custom Questions you add (short-answer, multiple-choice, or conditional). Your privacy policy must list each category of data the form collects and explain:

• Purpose of collection. Why you are collecting each field -- for example, "to send a quote by email" or "to schedule a consultation call." Vague purposes such as "to improve our services" do not satisfy Meta's Lead Ads Terms.
• Third-party sharing. Whether the lead data is sent to a CRM (Salesforce, HubSpot, Zoho), an email marketing platform (Mailchimp, ActiveCampaign), or any other downstream service. Name each recipient. If you use Meta's CRM Integration in the instant form settings to push leads directly to a third-party system, that data flow must be disclosed.
• Data retention and deletion. How long you keep the lead data and how someone who submitted the form can request deletion. Lead data downloaded from Ads Manager or received via the Leads API does not expire automatically on your end -- you are responsible for the retention lifecycle once it leaves Meta.

If you also use the Meta Pixel or Conversions API to send conversion events back to Meta when a lead converts (for example, firing a Lead event or a Purchase event), those data flows create a separate disclosure obligation covered in the next section. To generate a privacy policy that covers both Lead Ads form fields and Pixel event data, use the free privacy policy generator.

Privacy Policy for a Facebook Page and Meta Pixel / Conversions API

Running a Facebook Page, installing the Meta Pixel on your website, or sending server-side events through the Conversions API each triggers a privacy policy obligation under Meta's Business Tools Terms (formerly "Facebook Business Tools Terms"). These requirements are separate from App Review and apply to marketers, publishers, and business owners who never build a Facebook app.

Facebook Page privacy policy requirements

Any Facebook Page that collects information from visitors must make a privacy policy accessible. The collection happens through several built-in Page features:

• Messenger conversations. When a visitor messages your Page, Meta stores the conversation and makes the sender's name, profile picture, and Page-Scoped User ID (PSID) available to you through the Page Inbox or the Messenger Platform API. Your policy must disclose that you collect and store messages and sender identity data from Facebook Messenger.
• Page Insights. Meta provides Page administrators with aggregated demographics and engagement data through Page Insights (accessible at Page > Insights or via the read_insights Graph API permission). Under the GDPR, Page administrators and Meta are joint controllers for the processing that produces Page Insights data, as established by the Court of Justice of the European Union in Wirtschaftsakademie (Case C-210/16). Your policy should state that you receive aggregated analytics about Page visitors from Meta.
• Shop and checkout. Pages with an active Facebook Shop collect order information (name, shipping address, email, payment method) through Meta's Commerce Manager. Each data point collected at checkout must appear in your privacy policy.

You can add your privacy policy URL in Page Settings > Page Info > Privacy Policy (under the "Additional Information" section). While Meta does not block a Page from operating without this field, running Lead Ads, Commerce features, or Messenger automations from a Page without a linked policy violates Meta's terms and exposes you to enforcement action.

Meta Pixel disclosure obligations

The Meta Pixel (formerly Facebook Pixel) is a JavaScript snippet you install on your website that fires HTTP requests to facebook.com/tr/ whenever a visitor loads a page or triggers an event. Section 2 of Meta's Business Tools Terms requires you to provide clear and prominent notice to your website visitors about the data you collect and share with Meta through Business Tools, and to obtain any consent required by applicable law before using them.

The Pixel collects and transmits the following data to Meta with every event fire:

• Browser and device data: IP address, User Agent string, screen resolution, browser language, and time zone.
• Page data: the full URL of the page viewed, the referring URL, and the page title.
• Facebook cookies: the _fbp first-party cookie (a browser identifier set by the Pixel) and the _fbc cookie (which stores the click identifier from an ad click, fbclid).
• Event parameters: for standard events like ViewContent, AddToCart, Purchase, or Lead, the Pixel sends event-specific parameters you configure -- product IDs, values, currencies, content categories.
• Advanced Matching data (if enabled): when you turn on Automatic Advanced Matching in Events Manager > Settings > Advanced Matching, the Pixel reads form fields on your page and hashes and sends personal data including email address, phone number, first name, last name, city, state, zip code, date of birth, and gender to Meta for identity resolution.

Your privacy policy must disclose that you use the Meta Pixel, name the categories of data listed above that apply to your implementation, state that this data is shared with Meta for ad measurement and optimization, and explain how visitors can opt out. Point users to Meta's Ad Preferences page and to your own cookie consent mechanism if you operate one.

Conversions API disclosure obligations

The Conversions API (CAPI, formerly Server-Side API) sends event data from your server directly to Meta's graph.facebook.com endpoint, bypassing the browser. You configure it in Events Manager > Settings > Conversions API or through a partner integration (Shopify, WordPress, Google Tag Manager server container). The data you send through CAPI is structurally the same as what the Pixel collects -- event name, event parameters, and user data parameters for matching -- but because it is server-to-server, it can include data the browser Pixel never sees, such as CRM records, offline purchase data, or call center outcomes.

Meta's Business Tools Terms apply to CAPI identically to the Pixel. Your privacy policy must disclose:

• That you send event data from your server to Meta for ad measurement, optimization, and audience building.
• The categories of user data parameters you include in CAPI payloads -- typically hashed email (em), hashed phone (ph), IP address (client_ip_address), User Agent (client_user_agent), and the Facebook click ID (fbc) and browser ID (fbp).
• Whether you send offline events (in-store purchases, phone orders) through CAPI, and if so, that customer data from those transactions is shared with Meta in hashed form.

If you run both Meta Pixel and Conversions API (the setup Meta calls redundant event tracking for deduplication), a single disclosure section in your privacy policy can cover both, as long as it names both the client-side Pixel and the server-side API and describes the data each transmits. Generate a free privacy policy that includes Meta Business Tools disclosures alongside your other data practices.

Why App Review Rejects a Privacy Policy URL

Rejection notes appear per permission under App Review > Requests. For privacy policy problems they trace back to the clauses quoted above:

1. URL not reachable by Meta's crawler. Clause 4.a requires a URL that is "easily accessible (including by our crawlers), and non-geoblocked." Login walls, VPN-only staging hosts, Cloudflare bot challenges, country blocks, and HTTP-only pages all fail. Meta's Privacy Policy Expectations page warns: "Broken privacy policy links are considered violations and are subject to enforcement." Check the response code in the Sharing Debugger before submitting.
2. Page is not clearly a privacy policy. The URL points to a homepage, About page, or terms of service with a privacy paragraph buried inside. The expectations page says "the linked page must be clearly marked as a privacy policy."
3. Someone else's policy. Linking to Meta's own Privacy Policy, an app store listing, or a template vendor's policy fails the "must be your own privacy policy" rule.
4. No deletion route. Clause 4.b requires the policy to explain "how Users may request deletion of that data," and the User data deletion field must hold a working instructions URL or callback. A contact page that never mentions deletion gets cited here.
5. Permission data missing from the policy. A template saying "we collect personal information" without naming the Facebook data each requested permission returns (see the table above) is rejected for that permission, even if the others pass.
6. Reviewer cannot test the app. Not a policy defect, but it fails the whole submission. Provide non-expiring test credentials without two-factor prompts, plus step-by-step instructions in the submission notes.

Fix the cited item, keep the same URL, and resubmit from App Review > Requests.

Copy-Ready Facebook App Disclosure Block

Add this block to your existing privacy policy to cover your app's Facebook integration. Replace the bracketed fields with your actual data practices and remove any sections that do not apply.

Need a complete privacy policy rather than just the Facebook section? Use the free privacy policy generator to build a full policy that covers GDPR, CCPA, and app store requirements, then host it at a permanent URL you can paste into your App Dashboard.

Frequently Asked Questions