At the root of your developer domain: the domain name in the developer URL on your app store listing, after that URL has been canonicalized. A www. or m. prefix is dropped, and at most one subdomain label is kept.

An app-ads.txt file is never found by crawling your app. A verifier reads the appstore:developer_url value from your store listing, takes the host out of it, reduces it as above, and asks that domain for /app-ads.txt over HTTPS and then HTTP.

So a listing pointing at https://www.example.com/our-apps results in a request for https://example.com/app-ads.txt.

Why this is worth checking twice

Publishing the file one label too deep is invisible from every direction. The file is there, it returns 200, it validates perfectly, and no record in it is ever seen by anybody. There is no error to find, so the only symptom is demand that never arrives.

Paste your file's URL into our ads.txt and app-ads.txt validator and it will tell you the exact URL a verifier will request for it, alongside the usual validation of the file itself.

A few specifics

• A file on a subdomain is authoritative for that subdomain, and the parent domain is only a fallback, so publish on the domain your listing actually names.
• One redirect is allowed, and it may point off your domain, which is what makes our Connect Hosting option valid for app-ads.txt. A second redirect is an error.
• If you need different sellers for different apps, that needs a separate developer domain or subdomain per app: one app-ads.txt file cannot authorise sellers per app.
• Your ads.txt file is unaffected. It is still read from the exact host a crawler found, so the two files can live on different domains if that is what your listings say.

For managing the file itself, see Manage: app-ads.txt Files.