Ads.txt, app-ads.txt and sellers.json: what buyers can verify

Published: September 10, 2026.

Supply chain transparency is not a branding exercise. For a buyer, it is a practical check before budget moves from a plan into live programmatic inventory. For a publisher, it is a way to make authorized sales relationships visible before a buyer has to ask for a manual explanation.

The three files and signals that usually matter in that check are ads.txt, app-ads.txt, sellers.json, and the OpenRTB SupplyChain object. They do not prove that every impression is valuable, viewable, or fraud-free. They do help answer a narrower and very useful question: is the seller in this transaction allowed to sell this inventory, and can the buyer identify the companies in the path?

What ads.txt proves on a website

Ads.txt is the publisher-side public record for web inventory. IAB Tech Lab describes it as a method publishers and distributors can use to declare the companies they authorize to sell digital inventory. In practice, the buyer or platform checks the publisher domain, fetches the file from the root of the site, and compares the listed advertising system and seller account with the bid request.

A clean ads.txt file does not say that a placement will convert, that traffic is human, or that the final price is fair. It says that a named ad system and account are authorized in the publisher record. That is still important because domain spoofing and unauthorized resale often start with a simple mismatch: the bid request claims one source, but the public authorization file does not support that selling path.

For publishers, the operational lesson is simple: keep the file short enough to maintain, remove inactive partners, avoid stale reseller entries, and make sure the domains and seller IDs match the commercial relationships that actually exist. If a partner manages inventory on the publisher's behalf, the current ads.txt 1.1 fields for owner and manager domains can make that relationship easier to reconcile with sellers.json.

When app-ads.txt is the right file

App-ads.txt takes the same authorization idea into mobile apps, connected TV apps, and other app-store environments. The key difference is discovery. A website has an obvious root domain; an app needs its developer website or app-store metadata to lead buyers and crawlers to the correct file. That makes app-store hygiene part of ad quality. If the developer URL is wrong, missing, or controlled by a different entity, the authorization chain becomes harder to trust.

Advertisers should treat app-ads.txt as a first screen for app inventory, not as the whole review. A matched line is useful; an absent or contradictory file is a reason to slow down and ask questions. For publishers and app owners, keeping app-ads.txt aligned with the active monetization stack avoids unnecessary demand loss when buyers enforce authorized-seller targeting.

What sellers.json adds

Ads.txt answers who is authorized by the publisher. Sellers.json answers who an advertising system says its seller IDs represent. IAB Tech Lab explains that sellers.json lets buyers discover entities that are direct sellers or intermediaries in digital advertising. That matters because an account ID in ads.txt is not very helpful if the buyer cannot connect that ID to a company name, domain, and role.

The most useful buyer check is reconciliation. The publisher domain has an ads.txt entry for an exchange or SSP. The exchange or SSP publishes sellers.json. The seller ID in the bid path should map to a visible seller entry, unless there is a clearly documented confidential treatment. If the account is marked as an intermediary, the buyer should understand why that intermediary is in the route and whether the path is still commercially sensible.

For SSPs and exchanges, sellers.json is not a landing page. It is machine-readable infrastructure. It should be accessible, current, and internally consistent. Broken JSON, missing seller IDs, unexplained confidential rows, and domains that do not match the publisher relationship all reduce buyer confidence even when the media plan looks attractive.

Where the SupplyChain object fits

The SupplyChain object, commonly seen as schain, travels with the bid request. It lists the nodes that participate in selling or reselling a given opportunity. In the IAB Tech Lab specification, each node identifies the advertising system and seller ID, and the chain can be marked complete or incomplete. That gives buyers a transaction-level view instead of only a set of static files.

The important nuance is that these signals work together. Ads.txt or app-ads.txt shows authorization from the inventory owner. Sellers.json helps identify the seller IDs published by the selling platform. The SupplyChain object shows the path in the actual bid request. If those three views disagree, the buyer has a quality question before there is a performance question.

A practical buyer workflow

Before scaling spend, a buyer can run a simple sequence:

• Confirm the site or app identity in the bid request and landing context.
• Check ads.txt or app-ads.txt for the advertising system, seller ID, and direct or reseller relationship.
• Open the selling platform's sellers.json and reconcile the seller ID with the declared seller type, name, and domain.
• Inspect the SupplyChain object to see whether the path is complete and whether every intermediary is expected.
• Compare the result with other quality signals, including invalid traffic patterns, placement reporting, viewability, and post-click behavior.

This workflow should not become a box-ticking ritual. A direct path can still deliver poor traffic. A reseller path can be legitimate when it is documented and commercially understood. The point is to make hidden risk visible early enough to change the buying decision.

What publishers should prepare

Publishers do not need to turn transparency into a long sales document. They need the basics to be accurate. The ads.txt file should reflect current authorized partners. App owners should verify the app-store developer URL and the app-ads.txt location. Commercial teams should know which relationships are direct, which are reseller paths, and which partners publish the relevant sellers.json records.

That preparation also supports monetization. Buyers are more comfortable testing inventory when they can understand the source, the seller relationship, and the reporting path. It complements the broader publisher monetization workflow instead of replacing it.

How this connects to quality, not promises

Transparency standards do not guarantee campaign results. They reduce ambiguity. They help buyers avoid misrepresented inventory, help publishers control authorized sales channels, and give both sides a shared language for supply path discussions. After that, the normal quality review still matters: fraud signals, placement-level reporting, frequency, pricing model, and conversion quality.

For that reason, Adstean treats supply chain checks as one part of a broader buying conversation. Advertisers comparing inventory sources can combine this review with ad-fraud signal checks and supply quality signals before deciding whether a source deserves more budget. If the transparency layer is unclear, the sensible next step is not to assume fraud; it is to slow down, ask for the missing evidence, and buy only what can be explained.

For campaign teams ready to review inventory paths before they scale, the advertiser workflow is the right place to start.

Sources: IAB Tech Lab on ads.txt and app-ads.txt, IAB Tech Lab on sellers.json and the SupplyChain object, and the IAB Tech Lab OpenRTB SupplyChain object specification.