Why we publish app-ads.txt and sellers.json on day one

An exchange asks buyers to spend money on inventory they cannot see being served. The only thing that makes that reasonable is a verifiable answer to one question: is the entity selling this impression actually authorized to sell it? The IAB Tech Lab built three plain-text files to answer exactly that, and oxavane published all three before it routed a single bid. This is what they are, what they declare, and why we treat them as a precondition for doing business rather than a box to check later.

Three files, one job: prove the supply chain

ads.txt (Authorized Digital Sellers) is a flat file a publisher hosts at the root of its domain — /ads.txt — listing every advertising system authorized to sell that publisher's inventory. app-ads.txt is the same idea extended to mobile and connected-TV apps: because an app has no web root to host a file at, the spec resolves the developer's website from the app-store listing and looks for /app-ads.txt there. sellers.json is the mirror image, published by the advertising system itself: it names every seller and intermediary in that system's accounts so a buyer can resolve a numeric account ID back to a real, named company.

Together with the SupplyChain object passed in the bid request, these files let a buyer trace an impression end to end — from the app or screen it ran on, through every intermediary, to the seller getting paid — and confirm that each hop was declared and authorized. Nothing about the path is implied or taken on faith.

What a line actually declares

Each record in ads.txt and app-ads.txt is a single line with three required fields and one optional one:

• The advertising system's canonical domain — the host the bid clears through, written exactly as that system publishes it.
• The seller's account ID — the specific publisher account inside that system. This is the seller's own account, not a shared or borrowed one.
• The relationship — DIRECT if the publisher controls the account and the inventory directly, or RESELLER if an authorized intermediary is selling on the publisher's behalf. The distinction matters: a buyer paying a premium for owned-and-operated supply does not want to discover it routed through a chain of resellers.
• The certification authority ID — an optional but recommended identifier that ties the advertising system to its entry in the IAB Tech Lab's authority registry.

A companion directive, OWNERDOMAIN, declares the canonical domain of the company that owns and operates the inventory. It lets a buyer collapse a publisher's many properties and subdomains back to a single accountable owner, which is precisely the information a spoofer works to obscure.

What sellers.json adds

Where ads.txt lets a publisher vouch for its sellers, sellers.json makes the seller vouch for itself. Each entry maps a seller_id to a named entity and a type — PUBLISHER when the account owns the inventory, INTERMEDIARY when it passes inventory through, or BOTH — alongside the seller's domain. A responsible exchange declares its sellers transparently rather than masking them as confidential, so that a buyer resolving an account ID gets a real company name on the other end, not a dead reference.

How buyers actually use them

Verification is not theoretical; it is wired into the bidding path. A demand platform crawls these files continuously and builds a map of who is allowed to sell what. When a bid request arrives, the platform checks the seller account and SupplyChain against that map before it decides whether — and how much — to bid. Three failure modes get caught this way:

• Domain spoofing — a low-value or fraudulent property dressing up its bid requests to look like premium inventory. If the claimed seller is not authorized for that inventory in ads.txt, the bid is worthless and gets discarded.
• Unauthorized reselling — an intermediary passing inventory it was never granted the right to sell. A SupplyChain hop that does not reconcile against the relevant sellers.json entries is a red flag.
• Counterfeit app inventory — bid requests claiming to come from an app whose developer never authorized that seller in app-ads.txt. The mismatch is detectable before a single dollar moves.

The economic effect is direct: complete, accurate transparency files raise a buyer's confidence and willingness to bid, while gaps and contradictions suppress it. Transparency is not a courtesy to the buyer — it is what makes the inventory worth more.

Why day one, not someday

Plenty of intermediaries treat these files as housekeeping — something to backfill once volume justifies the effort. We think that reasoning is backwards. The supply chain is the product an exchange sells; if it cannot be verified on the first day, there is nothing trustworthy to scale on the hundredth. Publishing late also normalizes a window in which the path from impression to seller is unauditable, and that window is exactly where spoofing and unauthorized reselling live.

So we did it first. Our files are live, maintained continuously, and current with the relationships we actually run — declaring our authorized sellers, our owner domain, our own accounts, and each relationship as DIRECT or RESELLER without ambiguity. None of it names a confidential demand partner or a publisher we represent under NDA, because none of it needs to: the standard is about proving authorization, not exposing commercial relationships.

What this says about how we operate

Transparency by default is a posture, not a feature. The same instinct that makes us publish these files on day one is the one that settles publishers on a fixed schedule, declines exclusivity, and curates the supply we connect rather than inflating a number on a rate card. An exchange that is comfortable being inspected tends to be comfortable being inspected everywhere. Verification should never require a phone call — it should require a URL.

If you are a buyer evaluating our supply, or a publisher deciding whether to connect inventory, start by reading the files. They are the most honest thing we can hand you.

---

Read the files

← Back to the Journal

Buyer or publisher with a supply-chain question? Write to partnerships@oxavane.com — a human replies within one business day.