Quick definition
App-ads.txt is an IAB Tech Lab standard that lets an app publisher publicly declare which seller accounts are authorized to sell its advertising inventory. The declaration is published as a text file on the developer website associated with the app's store listing. Advertising systems can use it to check whether a represented selling relationship is authorized.
The standard extends the authorized-seller approach used by ads.txt for websites to applications, including relevant mobile and connected-TV distribution contexts. It addresses a particular supply-chain question: who is allowed to sell this inventory?
It does not certify every impression as genuine, guarantee ad quality, or replace all fraud controls. An authorized seller can still be involved in an impression with other problems. Treat the file as one important declaration within a broader verification process, not a universal certificate of safe advertising.
Understand the app-to-domain connection
An app is distributed through a store rather than inherently identified by a publisher's web domain. App-ads.txt uses the developer website information associated with the store listing to connect the application with a domain where authorization can be published.
The file is normally made available at the applicable developer-domain root path named app-ads.txt, following the specification's discovery rules. Platform implementations may provide specific setup and diagnostic guidance. Verify the domain actually published in the listing rather than assuming a support email or an unrelated marketing URL supplies the same connection.
Keep web and app teams coordinated. A domain migration or store-listing edit can affect discovery even when the file itself has not changed. The public association, accessible file, and seller records need to remain consistent for buyers to interpret the declaration correctly.
Read the seller record accurately
A basic seller record identifies an advertising-system domain, the seller account identifier within that system, and a relationship type. An optional certification-authority identifier may also be present. Obtain the correct values from the relevant authorized partner and verify them against the actual commercial relationship.
DIRECT indicates that the publisher directly controls the account represented by the seller identifier. RESELLER indicates an authorized intermediary relationship for that account. The distinction is about the relationship to the listed account, not simply whether the advertiser considers the buying path short or inexpensive.
Do not copy another app's records as a shortcut. A valid-looking account identifier can authorize the wrong entity. Maintain an internal explanation for each entry, including the partner, account, relationship, and owner who approved it. The file should describe real authorization rather than accumulate every line suggested by an unfamiliar party.
Publish and validate the complete setup
Create a plain-text file with the approved records and publish it at the required location. Confirm that the public request returns the intended content, not a website template, login screen, or error page. A successful HTTP response alone does not establish that the file contains usable records.
Check the app store's developer website, the file's accessibility, record syntax, account identifiers, and relationship values. Use the relevant ad platform's diagnostics and allow for its documented crawling and processing behavior. Do not assume every system refreshes immediately after an edit.
Assign an owner for both the file and the relationships it represents. Technical deployment and commercial authorization are separate checks. A developer can confirm that the file loads, while the monetization owner must confirm that the listed accounts are genuinely authorized to sell the app's inventory.
Worked example: finding a discovery mismatch
Imagine a fictional app publisher whose store listing identifies example.com as its developer website. Its monetization team places the authorization file on a different campaign domain and sees an unresolved authorization warning. The file contains the expected seller record, but the discovery path does not lead buyers to it.
The team verifies the intended developer-domain association and publishes the approved file at the correct location. It then checks the public response and relevant platform diagnostics. It does not solve the problem by adding unrelated seller accounts or copying a competitor's file.
If the warning persists, the team reviews processing delay, domain handling, syntax, and account identity separately. This example shows why troubleshooting must follow the complete chain from app listing to domain to seller record. A technically accessible file on the wrong domain may not establish the required authorization.
Maintain authorization as partners change
Review entries when adding or ending monetization relationships, changing account identifiers, or migrating developer domains. Remove obsolete authorization through a controlled process after confirming the relevant relationship and transition requirements. An old record should not remain indefinitely simply because nobody owns the file.
Keep a version history with approval context. This helps investigate an unexpected change and distinguishes a legitimate partner update from an accidental or unauthorized edit. Restrict publishing access appropriately because the file communicates which accounts may sell the inventory.
Coordinate changes with monetization and engineering teams. Removing a required entry can affect eligible buying, while adding an incorrect entry can misrepresent authorization. Test after deployment and monitor platform feedback. The small size of the file should not make it an unmanaged configuration artifact with potentially significant commercial consequences.
Interpret verification without overclaiming protection
A valid authorization match answers one supply-chain question. It does not prove that an impression was viewable, shown to a human, placed in a suitable context, or sold through an economically efficient path. Other controls and evidence remain necessary.
App-ads.txt can be considered alongside seller transparency information and other supply-chain checks. Understand what each mechanism establishes rather than treating several passing labels as interchangeable proof of overall quality.
When reporting an issue, distinguish missing discovery, inaccessible content, malformed records, absent seller authorization, and unrelated inventory-quality concerns. These problems have different owners and remedies. A precise diagnosis helps avoid unnecessary changes to a correct file and prevents teams from promising that one configuration adjustment will eliminate every source of ad fraud or monetization difficulty.
Frequently asked questions
Is app-ads.txt the same file as ads.txt?
They use the same authorized-seller concept but serve different inventory contexts and filenames. Ads.txt applies to website inventory, while app-ads.txt connects app inventory through the developer-domain discovery process. Do not assume that publishing one automatically satisfies the other. Follow the relevant standard and platform guidance for the inventory being sold and verify the actual location used for discovery.
Where should the file be hosted?
It should be published at the applicable developer-domain location identified through the app's store listing and the standard's discovery rules. Check the actual developer website shown publicly and the relevant ad platform's setup instructions. An accessible file on an unrelated campaign domain may not be discovered. Verify the full association rather than only confirming that some URL ending in app-ads.txt loads.
Can I use seller records from another app?
No, not without verifying that they accurately represent your own authorized accounts and relationships. Seller identifiers are specific to accounts within an advertising system. Copying a valid-looking line can declare authorization for the wrong entity. Obtain records from the relevant partners, confirm their meaning, and maintain an internal owner and approval record for each entry you publish.
Does a valid file eliminate ad fraud?
No. It helps buyers check whether a seller account is authorized for the inventory. Other problems, such as invalid traffic, unsuitable placement, or misleading representations elsewhere in the supply chain, require additional evidence and controls. Treat authorization as one layer of verification. A passing file check should not be presented as a guarantee that every impression is genuine or commercially valuable.
Why might a corrected file still show a warning?
Possible causes include processing delay, an incorrect developer-domain association, inaccessible content, syntax errors, or a seller identifier that does not match the expected account. Check each stage separately using current platform diagnostics. Do not repeatedly change correct records without evidence. Preserve the previous version and document what was changed so troubleshooting remains understandable and does not introduce new authorization mistakes.
Related terms
- Ads.txt: the authorized-seller declaration used for website inventory. App-ads.txt extends the approach to application distribution contexts.
- Sellers.json: seller transparency information published by advertising systems. It addresses related identity questions within the supply chain.
- Supply-side platform: technology supporting publisher inventory sales. Its account relationships may require authorization records.
- Programmatic advertising: automated buying and selling of advertising. Authorized-seller checks support transparency within that ecosystem.
- Ad fraud: deceptive activity affecting advertising outcomes. App-ads.txt addresses only certain authorization-related risks.
- App store listing: the public app page containing relevant developer information. Its website association supports file discovery.