sellers.json Explained: Read Seller Roles Without Overstating What They Prove
sellers.json Explained: Read Seller Roles Without Overstating What They Prove
sellers.json is an IAB Tech Lab transparency specification for the sell side of programmatic advertising. It provides a structured way for an advertising system to publish information about sellers and intermediaries in its system. The information can help other participants interpret a supply-chain relationship, especially when a bid request alone does not provide enough context.
Like other transparency tools, sellers.json is best treated as evidence with a defined scope. It can describe a published record. It does not independently prove that a seller is legitimate, that every transaction is authorized, that inventory will perform as expected, or that every commercial obligation will be met.
Why the specification exists
IAB Tech Lab explains that sellers.json can identify sellers and intermediaries involved in selling a bid request and allow relevant information to be looked up outside the bid request itself. That is useful because advertising transactions can involve several organizations and technical systems. A published file gives participants a common place to look for a system’s stated seller information.
The file supports transparency; it does not eliminate ambiguity. A record still needs to be read in context with other technical signals, the relevant contractual relationship, and the scope of the review being performed.
What a reviewer can observe
A sellers.json review can document observable details such as the advertising system hosting the file, a seller identifier, a seller type, a name or domain when disclosed, and whether the record is visible at the time of retrieval. These observations are useful for forming questions and reconciling identifiers across systems.
A reviewer should preserve the distinction between an observation and an inference. “The record lists this seller ID as an intermediary” is an observation. “The intermediary is trustworthy” is an inference that the record alone cannot support.
Read seller types as roles, not verdicts
The specification uses seller-type information to distinguish the role an entity says it plays in a system. The field is helpful for mapping a path, but it should not become a shortcut for evaluating a company. A role label does not state the economics of a transaction, the quality of inventory, the contractual authority for a specific deal, or the behavior of every participant downstream.
Similarly, an incomplete public record should be described carefully. It may reflect a configuration issue, a disclosure choice, a recent system change, or another condition that needs clarification. It is not, by itself, proof of misconduct. Escalate the discrepancy to the owner who can explain the account, relationship, or implementation.
Pair sellers.json with the right questions
Before opening a file, write down what you are trying to learn. A useful question might be: “Can we reconcile the seller identifier in this transaction with the advertising system’s published seller information?” That question is appropriately narrow. Questions such as “Is this inventory safe?” or “Will this campaign meet its goal?” require evidence outside sellers.json.
For authorization questions, a team may also need to inspect the publisher’s ads.txt declaration. For protocol questions, it may need to consult the applicable OpenRTB or supply-chain specifications. For measurement questions, it may need reporting definitions and methodology. For commercial questions, it may need the relevant agreements and contacts. Keeping these questions separate makes a review easier to audit.
A restrained reconciliation checklist
- Capture the file URL and the date and time it was retrieved.
- Record the advertising-system domain and the seller identifier under review.
- Note the published seller type and any disclosed name or domain.
- Compare identifiers with the transaction or platform context, checking for simple formatting differences first.
- State only what the published record shows; list unresolved questions separately.
- Route discrepancies to a responsible technical or commercial contact rather than assigning blame in the report.
Report the limits alongside the finding
A strong review note has two parts. First, it records the finding: “On the retrieval date, the advertising system’s sellers.json file listed seller ID X with seller type Y.” Second, it records the boundary: “This check does not assess the quality, authorization, or performance of a particular impression or commercial relationship.”
That second sentence is not hedging. It prevents a transparency check from being used as a claim it cannot support. It also makes room for the next appropriate review, whether that is an ads.txt comparison, a technical implementation check, or a conversation with the organizations involved.