Skip to content
AppFoyer
Start free

Guides

Every URL you need before submitting an app

The full list across Play Console, App Store Connect and AdMob, which ones are required rather than optional, what each page has to contain, and the order to do them in.

Most apps need four public URLs: a privacy policy, an account-deletion page if the app has accounts, a support page for the App Store, and a developer website if it shows ads. Each is a separate console field, each is checked, and all of them have to keep working long after the app is approved.

Checked 19 September 2026. Store policies change, sometimes without notice. Everything below links to the official documentation, and that page — not this one — is the authority. If the two disagree, the store is right.

This is the list nobody gives you before your first submission, so you discover it one rejection at a time. Gather these before you open the console and the whole thing takes an afternoon instead of three review cycles.

The fields, by console

URLConsole and fieldRequired?
Privacy policyPlay Console → App content → Privacy policy; App Store Connect → App PrivacyYes, both stores
Account deletionPlay Console → App content → Data deletionYes, if the app has accounts
SupportApp Store Connect → the version’s Platform version information → Support URLYes, Apple
Developer websitePlay store listing; App Store Connect Marketing URLPlay: optional, but required in practice if you show ads — it is where app-ads.txt is looked for. Apple’s Marketing URL is genuinely optional
Contact emailPlay Console → Store settings → Store listing contact detailsYes, Play requires an email to publish

Apple also requires account deletion, but as an in-app route rather than a URL field — see the App Store account deletion guide.

What each page has to contain

Privacy policy. What is collected, why, who else sees it, how long it is kept, how to contact you. The section that gets you rejected is “who else sees it”: it has to name the third parties, which means every SDK in your build, and it has to agree with your Data safety answers.

Account deletion. A public page, reachable without signing in or having the app installed, where a user can ask you to delete their account. It must actually deliver the request to you — a page that displays a form and drops the result is worse than no page, because the user believes it worked.

Support. A route to a human. An email address you read is enough. Not your marketing page, not an App Store listing, not a social profile.

Developer website. A page about your app, at a hostname you control — and the hostname whose root an ad network will fetch /app-ads.txt from.

The four tests every one of them has to pass

The same four, every time, which is why it is worth doing them as a batch:

  1. It loads signed out. Open it in a private window. The classic failure is a page that works only because you are logged in to the service hosting it.
  2. It is not a redirect chain. Especially for app-ads.txt, which must be served directly.
  3. It names your app and your company. A policy naming a different app is the copy-paste tell, and reviewers notice.
  4. It will still be there in two years. A listing is checked more than once, and a free host you forgot about is the most common way a live app breaks.
curl -i https://your-url.example/privacy

200 OK, readable content, no Location: header.

The order to do them in

  1. Decide where all of them live, once. Splitting them across a Notion page, a GitHub Pages site and a form service is how you end up with three things to maintain and one that will break.
  2. Write the privacy policy from your dependency list, not from a template. Open build.gradle / Podfile / pubspec.yaml and work down it.
  3. Build the account-deletion route — the in-app one and the web one. This is the only item with real engineering in it, so it decides your timeline.
  4. Publish, then fill in the console fields. Not the other way round: a field pointing at a page that does not exist yet is the rejection you are trying to avoid.
  5. Fill in Data safety / App Privacy from the same list you wrote the policy from, so the two cannot disagree.
  6. app-ads.txt last, and only if you show ads.

What AppFoyer does here

This list is the product. All five pages — home, privacy, terms, support, account deletion — plus app-ads.txt go live together on your app’s own subdomain, so you paste working URLs into every field in one pass. The account-deletion page receives the request and notifies you; you do the deletion in your own systems.

There is also a checklist in the dashboard that tells you which console field is still empty and why it matters. One app is free, and nothing a store requires is ever behind a paywall.

The authoritative sources


Do this in a few minutes instead

AppFoyer hosts the pages this guide is about — privacy policy, terms, support, account deletion and app-ads.txt — on their own subdomain, with no domain or server of your own. One app is free, and nothing a store requires is ever behind a paywall.