Basics

What is app-ads.txt? The file, the format and where it goes

By Stoqlab team · Updated 11 October 2026 · 7 min read

app-ads.txt is a plain-text file an app developer publishes on its own website to list every company allowed to sell the ad space in its apps. Buyers and sell-side platforms read it before they trust a bid request that claims to come from one of those apps. If the seller in the request is not in the file, the request is treated as unauthorised, and most buyers will not bid on it.

The IAB Tech Lab defines the format in the app-ads.txt specification, an extension of ads.txt 1.1 for the web. The app version adds one thing: a way to find the file starting from an app store listing. Everything inside the file follows ads.txt.

What problem it solves

A bid request for an in-app impression names the app (its bundle ID and store URL) and the seller (an account on an SSP or ad network). Anyone can put any app's bundle ID in a request. Without a public list from the developer, a buyer cannot tell the app's real sellers from someone selling fake inventory under its name, a practice called spoofing. app-ads.txt is that list: the developer controls the website, so only the developer can say who may sell.

It covers the first hop only. The file says which accounts may sell; whether the traffic behind them is real, and who else handled the request after the first seller, are questions for invalid-traffic screening, sellers.json and the SupplyChain object. The specification also admits that a dishonest platform could rewrite an unauthorised account ID into an authorised one; the file cannot prevent that.

The line format

Each authorised seller is one line with up to four comma-separated fields:

<ad system domain>, <account ID>, <DIRECT|RESELLER>, <certification authority ID>

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
exchange.example, 98765, RESELLER
ssp.example, 4821, DIRECT

Field	What goes in it
1. Ad system domain	The canonical domain the SSP or network asks publishers to use. It is also where that company publishes its sellers.json. Required.
2. Account ID	Your account (or your reseller's account) on that system: the same value the system sends as `publisher.id` in bid requests and lists as `seller_id` in its sellers.json. Required.
3. Relationship	`DIRECT` if you control the account, `RESELLER` if you authorised another company to control it and sell your inventory. Case-insensitive. Required. See DIRECT vs RESELLER.
4. Certification authority ID	Optional. Usually the network's TAG ID. ads.txt 1.1 notes that identifiers in sellers.json supersede it and that the field may be deprecated.

Lines starting with # are comments. Anything after a ; on a line is an extension field and is ignored by parsers that do not know it. Exact values matter: an account ID with a missing prefix or an extra space will not match.

Variables

Besides seller lines, a file can hold VARIABLE=value lines. CONTACT says how to reach whoever maintains the file. OWNERDOMAIN and MANAGERDOMAIN, added in ads.txt 1.1, name the company that owns the apps and an exclusive or primary monetization partner; they have their own guide. INVENTORYPARTNERDOMAIN, added in 1.0.3, points to a content partner's ads.txt for shared inventory, which mostly matters for CTV apps. SUBDOMAIN exists in ads.txt but is unused in app-ads.txt and ignored if present.

Where the file must live

Verifiers start from the developer website in the app's store listing, not from your app. The app-ads.txt specification turns that URL into a file location in four steps:

take the host name of the developer URL;
keep only the registrable domain plus at most one subdomain (another.sub.example.com becomes sub.example.com);
drop a leading www. or m.;
request /app-ads.txt over HTTPS, falling back to HTTP.

Developer website in the listing	Where verifiers look
`https://www.example.com/games`	`https://example.com/app-ads.txt` (not on www)
`https://studio.example.com/`	`https://studio.example.com/app-ads.txt`, then `https://example.com/app-ads.txt` if none is found
`https://a.studio.example.co.uk/`	`https://studio.example.co.uk/app-ads.txt`, then `https://example.co.uk/app-ads.txt`

The response should be text/plain. Redirects within the same root domain are fine, and at most one redirect to another domain is allowed. An HTML page, a login wall or a bot challenge served at that URL is not a valid file, even if a browser shows something that looks right.

One file covers every app whose listing points to that domain, in every store. There is no way to authorise a seller for some of your apps only; if you need that, use separate domains or subdomains as developer websites.

If no one may sell

An empty file is ambiguous, since a server error page can look empty too. To say that no seller is authorised, publish the placeholder record the specification defines:

placeholder.example.com, placeholder, DIRECT, placeholder

Who reads it, and how often

SSPs and ad networks read it to check that the apps sending them requests have authorised the account in use. DSPs and verification companies read it to decide what to bid on. Google AdMob checks the app-ads.txt of apps before they serve, and limits serving for apps it cannot verify, so a correct google.com line matters for AdMob publishers.

Crawlers re-read files on their own schedules, from daily to monthly; ours is on the methodology page. When you change the developer website in your listings, the specification suggests leaving the old file in place for about 30 days so inventory is not left without a file while verifiers catch up. To see your file the way a verifier does, run the domain through the app-ads.txt checker; the errors guide explains whatever it flags.

Basics app-ads.txt vs ads.txt: what differs and what does not Basics DIRECT vs RESELLER in app-ads.txt Publishers Common app-ads.txt errors and how to fix them