Programmatic supply chain transparency relies on several mechanisms that describe different parts of the advertising supply chain. Ads.txt shows which companies a publisher authorizes to sell its inventory. Sellers.json provides information about the entities behind seller accounts, while the SupplyChain Object describes the participants involved in a particular bid request. Understanding how these mechanisms work individually provides the foundation for seeing how they can be used together to examine programmatic supply paths.
Table of Contents
Why Programmatic Supply-Chain Transparency Matters
What happens between the moment an advertiser pays for an impression and the moment that impression appears on a user’s screen? In programmatic advertising, the path is rarely as simple as it looks. An ad request can pass through several exchanges, resellers, and intermediaries before reaching the buyer.
This makes supply-chain transparency important. Without clear information about who is authorized to sell an impression, buyers may encounter inventory misrepresentation, where the actual publisher or placement differs from what was presented. Unauthorized reselling can add intermediaries that were never part of the intended deal. At the same time, long or opaque supply paths make it harder to understand where ad spend goes and who is involved.
Transparency helps buyers verify the relationships within the supply chain and build greater trust in programmatic transactions. It also supports Supply Path Optimization, which focuses on identifying more direct, efficient, and verifiable routes to inventory. Tools such as Ads.txt, Sellers.json, and the SupplyChain object provide the information needed to examine these relationships and support programmatic supply chain transparency.
What is Ads.txt?
What if a buyer could check whether a company is actually authorized to sell a publisher’s ad inventory? That is the basic idea behind ads.txt. The IAB Tech Lab defines ads.txt as a way for publishers to declare which companies are authorized to sell their inventory publicly. In other words, ads.txt explained simply: it is a publisher-controlled list of authorized inventory sellers.
Ads.txt is a publisher-side text file associated with a publisher’s domain. It contains records that identify advertising platforms, exchanges, and other companies permitted to sell the publisher’s inventory. Buyers and other participants in the advertising ecosystem can use these records to verify whether a seller is authorized.
Each entry typically includes a seller or account ID, which identifies the publisher’s account on a particular advertising platform. It also includes a relationship type: DIRECT means the publisher has a direct relationship with the identified platform, while RESELLER indicates that the company is authorized to resell inventory on behalf of another entity.
The file is tied to the publisher’s domain, allowing buyers to compare the domain where inventory is supposedly coming from with the companies listed as authorized sellers. However, ads.txt does not reveal the entire path an impression takes through the programmatic ecosystem. It primarily establishes which sellers are authorized to represent a publisher’s inventory.
What is Sellers.json?
If ads.txt tells buyers which companies a publisher has authorized to sell its inventory, sellers.json helps answer another question: who are those sellers? An advertising system, such as an SSP or exchange, publishes the file and provides information about the entities that sell inventory through that system.
A sellers.json entry typically includes a seller ID, which is the account or identifier used by the advertising platform. It also specifies the seller type, which helps distinguish roles in the supply chain. Depending on the system, a seller may be classified as a DIRECT, INTERMEDIARY, or BOTH entity.
The file can also include the seller’s name and domain. This information helps connect a technical account ID used in a bid request with an identifiable company or organization. For example, instead of seeing only an unfamiliar seller ID, a buyer can use sellers.json to determine which entity that ID represents and its role in the transaction.
The main function of sellers.json is therefore to link technical seller IDs to real entities. Used together with ads.txt, it gives buyers more context for checking who is authorized to sell inventory and which entities are involved in the broader supply chain. This is a key distinction when considering ads.txt vs sellers.json: ads.txt focuses on publisher authorization, while sellers.json focuses on seller identity and role.
What is the OpenRTB SupplyChain Object?
Ads.txt and sellers.json provide information about authorized sellers and their identities. But how can a buyer understand the specific chain involved in a particular bid request? This is where the SupplyChain Object, commonly referred to as schain, comes in. The schain OpenRTB mechanism provides a structured way to represent that transaction-specific supply path.
The SupplyChain Object is part of the OpenRTB framework and describes the entities involved in passing a bid request through the programmatic supply chain. It represents each participant as a node, allowing buyers to see which companies sell or resell the impression.
For example, a hypothetical path might look like: Publisher → SSP A → Exchange B → DSP
In the corresponding schain, each relevant participant is represented by a node. The nodes contain information such as the advertising system or seller account involved in that step. This creates a structured representation of the supply path associated with the specific bid request.
The key distinction is that schain provides transaction-level supply-chain information. While ads.txt describes which companies a publisher authorizes to sell its inventory, and sellers.json helps identify entities behind seller IDs, the SupplyChain Object shows the participants involved in a particular request. This makes schain useful for examining the actual route an impression takes and identifying the parties involved in selling or reselling it.
Ads.txt vs. Sellers.json vs. SupplyChain Object
These three mechanisms address different parts of programmatic supply transparency. Ads.txt focuses on authorization, sellers.json helps identify the entities behind seller accounts, and the SupplyChain Object (schain) describes the participants in a specific transaction.
| ads.txt | sellers.json | schain | |
| Published by | Publisher | SSP/exchange | Passed in bid request |
| Shows | Authorized seller accounts | Identity of sellers | Transaction path |
| Main purpose | Authorization | Identification | Path transparency |
The distinction becomes clearer when looking at how the information is used. A buyer can consult a publisher’s ads.txt file to check whether a particular platform is authorized to sell its inventory. Sellers.json can then help identify the entity associated with the seller ID that platform uses.
The SupplyChain Object adds transaction-specific context. Its nodes represent the participants involved in passing a particular bid request, helping the buyer understand which parties have handled or resold that impression.
These tools therefore complement rather than replace one another. Ads.txt establishes authorization, sellers.json helps identify the seller, and schain shows who participated in the transaction path. Used together, they provide a more complete view of programmatic supply relationships without relying on any single source of information.
How They Work Together
Understanding ads.txt, sellers.json, and the SupplyChain Object separately is useful, but their role becomes clearer when they are considered as parts of the same verification process. Each provides a different piece of information, and those pieces can be compared to build a more complete picture of how inventory moves through the programmatic ecosystem.
A buyer can begin with the publisher’s ads.txt file and check whether the seller or platform identified in the transaction is authorized to represent that publisher’s inventory. The relevant seller ID can then be matched against the SSP or exchange’s sellers.json file to determine which entity the account belongs to and its role in the supply chain.
The SupplyChain Object adds transaction-level context by showing the participants included in a particular bid request. Its nodes represent the entities involved in passing the request, making it possible to compare the reported supply path with the sellers identified through ads.txt and sellers.json.
The relationship can therefore be viewed as:
Publisher’s ads.txt
↓
Authorized seller ID
↓
SSP or exchange sellers.json
↓
Seller identity and role
↓
SupplyChain Object
↓
Participants in the bid request
Together, these sources let a buyer check authorization, identify the entities behind seller IDs, and examine the supply path reported for a specific transaction. When the information does not align, it can provide a starting point for further investigation.
Common Implementation Problems
The transparency mechanisms described above depend on information being maintained consistently across supply-chain participants. In practice, that information can become incomplete, outdated, or inconsistent. A publisher may leave an old seller in its ads.txt file after a commercial relationship has changed, while an SSP may keep using a seller ID that doesn’t match the information buyers find in sellers.json. These discrepancies can make it difficult to determine whether a seller is currently authorized and which entity is actually behind an account.
The relationship type recorded in ads.txt can create another source of confusion. If a seller is marked as DIRECT when the relationship is actually through an intermediary, or as RESELLER when the publisher has a direct relationship, the record does not accurately describe the supply arrangement. Domain mismatches can create similar uncertainty when the domains associated with a publisher, seller, or advertising platform do not align across the available records.
The SupplyChain Object can also provide an incomplete picture when one or more participants are missing from the chain. Conversely, a supply path with many resellers can be difficult to reconcile across multiple records, particularly when some sellers.json entries are marked as confidential, and their identities are not disclosed. In these situations, buyers have less information with which to verify the complete path.
These issues do not automatically indicate unauthorized inventory or an invalid transaction. They do, however, create gaps that make supply-chain verification more difficult and may require additional investigation.
How Buyers Use Supply Transparency for SPO
Supply transparency gives buyers more information about how an impression reaches the auction, but authorization alone does not mean that a supply path is efficient or suitable for every buyer. A seller can be legitimately authorized in ads.txt while the same inventory reaches the buyer through several intermediaries. For Supply Path Optimization, buyers therefore need to look beyond whether a seller is authorized and examine the path structure itself.
DSPs and other buying platforms can compare ads.txt records, sellers.json information, and the SupplyChain Object to evaluate the relationships involved in a transaction. This can help identify duplicate routes, unexpected intermediaries, incomplete supply chains, or paths that do not match the buyer’s requirements. Buyers can then apply their own criteria to determine which routes to include in bidding and which to exclude.
This process aims not simply to reduce intermediaries. Different supply paths can serve different commercial and technical purposes, and the appropriate path depends on factors such as inventory access, auction mechanics, fees, and the buyer’s objectives. Transparency provides the information needed to make these distinctions rather than treating every authorized route as equivalent.
For SSPs, this also creates a practical responsibility to maintain accurate seller information and provide consistent supply-chain data. Build a more transparent programmatic supply infrastructure with BidsCube SSP.
Final Thoughts
Ads.txt, sellers.json, and the SupplyChain Object provide different types of information, but their value becomes clearer when they are considered together. Ads.txt establishes which sellers a publisher has authorized, sellers.json helps identify the entities behind seller accounts, and the SupplyChain Object shows the participants involved in a specific bid request.
For buyers, this information provides a basis for examining how inventory moves through the programmatic ecosystem. It can help reveal inconsistencies, unexpected intermediaries, incomplete supply paths, and other issues that may require further investigation. At the same time, transparency should not be confused with an automatic assessment of supply quality or efficiency. A verified seller and a documented supply path are starting points for evaluating a route, not conclusions.
For publishers and SSPs, maintaining accurate and consistent information across these mechanisms is an important part of making supply relationships easier to verify. When authorization records, seller identities, and transaction-level supply paths correspond, buyers have a clearer basis for understanding the inventory they are purchasing and the route through which it reaches them.
This Article's Ad Tech terms
