ads.txt, app-ads.txt and sellers.json: a practical guide for publishers

Three small text files decide whether buyers trust your inventory enough to bid on it. When ads.txt, app-ads.txt or sellers.json are wrong or out of date, demand drops without any error message telling you why. This guide explains what each file does, how to write the entries correctly, and how to keep them accurate over time.

Why these files exist

Programmatic advertising lets many companies resell the same impression. That also made it easy for bad actors to pose as premium sites and sell mislabeled inventory, a practice known as domain spoofing.

IAB Tech Lab introduced ads.txt to fix this for websites, then extended the idea with app-ads.txt for mobile and CTV apps and sellers.json for the companies doing the selling. Together they let a buyer check two things before bidding:

• Is this seller authorized? The publisher’s ads.txt or app-ads.txt answers that.
• Who is this seller, really? The ad system’s sellers.json answers that.

Demand-side platforms (DSPs, the software advertisers use to bid) crawl these files automatically. If an impression arrives through a path the files don’t support, many buyers won’t bid.

ads.txt: authorizing sellers for your website

ads.txt (“authorized digital sellers”) is a plain text file hosted at the root of your domain, for example https://example-news.com/ads.txt. Each line names one company allowed to sell your inventory, in this format:

adsystem.example, 12345, DIRECT, abc123def
reseller.example, 98765, RESELLER

The four fields are:

1. Ad system domain. The canonical domain of the exchange or SSP (supply-side platform, the technology that sells publisher inventory). Use the domain the platform tells you to use, not a marketing site.
2. Seller account ID. Your account ID on that platform. It must match the ID the platform sends in bid requests.
3. Relationship type. DIRECT or RESELLER (explained below).
4. Certification authority ID. Optional. An identifier for the ad system from a certification body such as TAG, the Trustworthy Accountability Group.

The spec also supports a few variables. CONTACT lists who to reach about the file. OWNERDOMAIN states the business domain that owns the site, and MANAGERDOMAIN identifies a company that manages monetization on your behalf. SUBDOMAIN points crawlers to subdomains that publish their own file. Lines starting with # are comments.

app-ads.txt: the same idea for apps

Apps have no domain to host a file on, so app-ads.txt works slightly differently. The file uses the same line format as ads.txt, but it lives on the developer website listed in the app’s store listing (Apple App Store, Google Play, or a CTV app store).

Crawlers follow a chain: they read the bundle ID or store ID from the bid request, look up the store listing, find the developer URL, and fetch /app-ads.txt from that domain. That chain is where most app problems start:

• The developer URL in the store listing is missing, points to a social profile, or redirects somewhere unexpected.
• The file sits on a subdomain or subfolder instead of the root of the listed domain.
• The file is served with the wrong content type or behind a login or bot challenge.

If you publish apps, check the store listing as carefully as the file itself.

sellers.json: the other side of the handshake

ads.txt is published by the publisher. sellers.json is published by the ad system, at a location like https://adsystem.example/sellers.json. It lists every account the platform works with, so buyers can match the account ID in your ads.txt to a named business.

Each entry includes a seller_id, a seller_type and, unless marked confidential, a name and domain. The seller type is one of:

• PUBLISHER: the account owns the inventory being sold.
• INTERMEDIARY: the account resells inventory owned by someone else.
• BOTH: the account does some of each.

Publishers don’t write sellers.json, but you should check how you appear in each partner’s file. If a platform lists you as an intermediary while your ads.txt says DIRECT, buyers see a contradiction. Vortex publishes its own ads.txt, app-ads.txt and sellers.json for exactly this reason: the handshake only works when both sides are public and consistent.

DIRECT vs RESELLER, and the mistakes that cost demand

The relationship field is where most confusion lives. Use DIRECT when you (the publisher) hold the account on that platform and control it, meaning payments come to you. Use RESELLER when another company holds the account and is authorized to sell your inventory through it.

A simple test: whose name is on the contract with the ad system? If it’s yours, the line is DIRECT. If it’s a partner’s, the line is RESELLER, and the account ID is the partner’s ID, not yours.

The most common errors we see across the industry are predictable:

• Wrong relationship label. Marking reseller accounts as DIRECT to look more attractive. Buyers cross-check sellers.json, so this backfires.
• Typos in account IDs. A single wrong digit makes the line useless, and nothing warns you.
• Non-canonical domains. Using a platform’s alternate or marketing domain instead of the one it specifies.
• Formatting problems. Extra fields, stray characters, HTML served instead of plain text, or a byte order mark at the start of the file.
• Redirects and blocks. Redirecting ads.txt across domains, or putting it behind a firewall rule that blocks crawlers.
• Stale lines. Entries for former partners add risk without adding revenue.

Keeping the files accurate

These files are not a one-time task. Every new partner, ended contract or account change should trigger an update:

1. Assign an owner. One person or team approves every change.
2. Keep a source of truth. Store the file in version control or a shared sheet with a note for each line: partner, relationship, date added.
3. Review on a schedule. Remove lines for partners you no longer use and confirm the IDs still match partner dashboards.
4. Validate after every edit. Fetch the live file in a browser and with a command-line tool to confirm it returns plain text at the expected URL, without redirects.
5. Check the other side. Look yourself up in each partner’s sellers.json and confirm the name, domain and seller type match your ads.txt.

For apps, add one more step: whenever the developer website changes, confirm the store listing still points to a domain that serves app-ads.txt.

If you want a second pair of eyes on how your supply chain looks to buyers, the Vortex team works through these details with publishers every day. Learn how Vortex works with publishers.