Sellers.json and the SupplyChain Object: Ensuring Transparency for DSPs

79 percent of bid requests carried a SupplyChain object, and only 42 percent passed full validation, in the HUMAN Security measurement cited in coverage of the September 2026 IAB Tech Lab Programmatic Best Practices. That spread describes the state of supply transparency in programmatic: most of the ecosystem emits the object, and a minority emits it correctly. A DSP that cannot verify a path prices it as risk, discounts it, or moves spend to a path it can verify, and the publisher absorbs that decision as a lower clearing price with no diagnostic in a standard auction report.

Sellers.json and the SupplyChain object solve two halves of one problem. Sellers.json gives buyers a directory: a machine-readable file on each selling platform that lists every seller the platform pays. The SupplyChain object gives buyers a per request trace: the exact sequence of entities paid for one impression. A request that carries a valid chain, backed by a directory that resolves, lets the buyer identify the origin of the inventory, count the intermediaries, and price the path. A request without either forces the buyer to guess, and a guessing buyer bids lower.

This piece covers the field level mechanics of both standards, how Google Ad Manager shapes the chain under MCM, where chains break in practice, and a quarterly audit routine that fits a site above one million monthly pageviews. Agencies can hand the routine to any publisher client as a standing quarterly task, and a publisher can run it in an afternoon.

What sellers.json actually contains

Per the IAB sellers.json specification, the file gives buyers a mechanism to discover every entity that acts as a direct seller of, or intermediary in, the selling of digital advertising on a platform. Each entry carries five fields: seller_id, name, domain, seller_type and an is_confidential flag. The file lives at the root of the platform domain, so buyers can fetch it before a campaign starts and cache it.

The seller_type field takes three values, and each one tells the buyer something different:

• DIRECT: the platform pays this seller for inventory the seller owns, which normally means the domain field matches the domain the impressions came from.
• INTERMEDIARY: the platform pays this seller, but the seller does not own the inventory, the profile of a network or a reseller acting on the owner's behalf.
• BOTH: the account acts in either capacity depending on the impression.

The is_confidential flag controls visibility, not participation. A seller that opts into confidentiality hides the name and domain fields, but the seller_id still passes, so buyers can still count that seller, block that seller, or cap spend against that ID. Transparency in practice means the buyer sees an opaque identifier rather than nothing at all, and buyers weigh an opaque ID against the open entries next to it.

Buyers also use the file pre-campaign, not only at request time. A common workflow: fetch the platform's sellers.json, build an allow list of seller_id values that map to acceptable domains, cap or exclude the rest, then refetch on a schedule because platforms add and drop sellers constantly. If your entry disappears during a migration, your requests still flow, but buyers begin rejecting them at the seat level with no error surfaced back to you. Ads.txt answers the complementary question: ads.txt states which sellers a content owner authorizes, sellers.json states who a platform pays. A complete disclosure posture requires both files, and buyers check both.

The SupplyChain object, node by node

The SupplyChain object travels inside the bid request itself. Per IAB Tech Lab, it is composed of nodes, each node represents a specific entity that participates in the selling of a bid request, and the entire chain from beginning to end represents all sellers who were paid for an individual bid request.

OpenRTB 2.6 defines the fields each node carries:

• asi: the canonical domain of the entity, the domain whose sellers.json and ads.txt a buyer can fetch.
• sid: the seller identifier, which should match a seller_id in that entity's sellers.json.
• rid: a request identifier the seller assigns, which lets a buyer trace a payment dispute back to a single transaction.
• hp: whether the node pays for the inventory, set it to 1 for every party that takes payment on the request.
• complete: a flag on the whole object that marks whether the chain contains all nodes involved in the sale.

In a well-formed chain, the first node names the seller closest to the impression, normally the publisher, and each subsequent node names the next intermediary until the chain ends at the platform that issued the bid request. In Prebid, each bidder adapter accepts an schain object in its bidder configuration, so a wrapper can inject one canonical sequence into every bidder and keep the chain identical across paths. The seat that hands the request upstream appends its own node, and the buyer receives the full sequence in source.ext.schain rather than a summary.

IAB Tech Lab publishes both standards on its sellers.json and SupplyChain hub and treats the directory and the trace as one disclosure system. Buyers pull that material when they build validation logic, and publishers pull it when they debug a rejected node.

How a DSP validates a chain

Validation is a lookup exercise, and it runs at auction speed. The buyer takes the asi of the first node, fetches sellers.json on that domain, and matches the sid against a seller_id in the file. The buyer then checks the domain field against the domain the inventory claims, checks seller_type against expectations, and honors is_confidential where it applies. The buyer repeats the lookup for each node and reads the ads.txt file on each asi domain to confirm that the next hop appears as an authorized seller.

Walk a concrete example. A sports site sells through a network partner that wraps its Ad Manager inventory. The first node reads asi: sports.example.com, sid: the publisher seller ID, hp: 1. The second node reads asi: network.example.com, sid: the network's ID in its own sellers.json, hp: 1. The buyer fetches the network's sellers.json, confirms the sid, confirms that sports.example.com lists the network in ads.txt as authorized, and only then treats the impression as sourced. Any break in that sequence, a missing file, an unmatched sid, an unauthorized hop, downgrades the request.

Two outcomes follow. A chain whose asi does not resolve, or whose sid matches no seller_id, marks the path as unverifiable, and the DSP filters it or prices in risk. A chain that validates but shows three intermediaries between the impression and the buyer invites supply path optimization: buyers inside The Trade Desk, DV360 and Amazon DSP compare the net cost of the same impression across paths and consolidate spend on the cheapest verifiable route. Both outcomes move money, and both depend on the sell side emitting a chain that survives the lookup.

MCM changes the shape of your chain

Google Ad Manager sits between most large publishers and their buyers, because MCM puts Google in the payment path. Under MCM, Ad Manager classifies parent publishers as intermediaries in sellers.json, and each child publisher sells under its own seller ID. Those child seller IDs can run up to 64 characters, which matters downstream: a pipeline that assumes short identifiers can clip the sid and break the match against seller_id.

Ad Manager sets is_confidential to false by default for INTERMEDIARY and BOTH accounts, so an MCM parent publishes its own name and domain to every buyer that fetches the file. Google documents submitting child publisher seller IDs in its Ad Manager Help material, including how the product links a child publisher's ads.txt and sellers.json entries so buyers can connect the authorization to the directory.

The practical consequence: buyers see at least two nodes on every request, yours and Google's, and your node carries the child seller ID assigned to your account. If your ads.txt omits Google as an authorized seller, or your child seller ID mismatches the entry in Google's sellers.json, validation fails at your own node before the buyer evaluates anything else on the path. Publishers who pass that check at scale win the consolidation phase of supply path optimization rather than lose it to a path with one fewer intermediary but no verifiable origin.

The validation gap, in numbers

The September 2026 measurement quantifies how often that fails in the wild. 79 percent of bid requests carried a SupplyChain object, which means most of the ecosystem emits the object at all. Only 42 percent passed full validation, which means the majority of chains buyers receive contain at least one node they cannot resolve. The causes cluster: an asi domain with no live sellers.json behind it, a sid that matches no seller_id, a chain that omits the final seller, or a complete flag left at zero on a chain the seller could have finished.

Buyers do not treat an invalid chain as neutral. A DSP that cannot verify a path excludes it from campaigns that require verified supply or prices a premium into the uncertainty. The publisher sees the result as a lower sell-through rate or a weaker clearing CPM, and the standard auction report shows no reason, because the request failed validation before the auction rather than during it.

What the Programmatic Best Practices ask for

IAB Tech Lab published Programmatic Best Practices v1.0 on September 16, 2026, with comments open through October 16, 2026. The document recommends supporting schain and including an schain object in each bid request, which formalizes behavior buyers already enforce at the seat level. For publishers the timing matters: feedback before October 16, 2026 shapes how strictly the final text treats incomplete chains, and publishers running MCM carry the most implementation surface in that conversation, because their chains gain a node and a 64 character identifier scheme at the same time.

A working audit routine

Run this audit quarterly, and immediately after any change to your selling stack:

1. Fetch sellers.json from every platform that sells your inventory, including your own domain if you sell direct. Check name, domain, seller_type and seller_id against your records.
2. Capture a sample bid request from your stack, in Prebid analytics or from your SSP seat, and read source.ext.schain node by node.
3. For each node, resolve the asi domain, fetch that platform's sellers.json, and match the sid to a seller_id. Confirm the hp flag only on parties that actually take payment.
4. Set complete truthfully: 1 when the chain shows every paid party, 0 otherwise, and never leave it at a wrapper default.
5. Confirm your ads.txt authorizes every hop, and that each hop's ads.txt authorizes the next one.
6. Under MCM, rerun the audit after every delegation change, because child seller IDs and ads.txt lines change when the MCM relationship changes.

Agencies advising a publisher should add two checks to this routine. First, confirm every monetization partner in the media plan appears in the publisher's ads.txt with the correct relationship. Second, pull each partner's sellers.json entry for that publisher and verify the domain and seller_id match exactly, because a mismatch between how the partner declares the publisher and how the publisher declares itself breaks the lookup at the first hop.

Five failure modes that break chains

In practice, nearly every failing chain breaks in one of five ways, and each fix costs hours, not projects:

1. A stale sellers.json after a network migration. The platform keeps paying you under a new seller_id while your wrapper still emits the old sid, and every request fails the sid lookup until someone updates both sides.
2. A domain mismatch between asi and the domain field. The apex domain in one place, the www subdomain in the other, and an exact string match fails. Pick the canonical form and enforce it in both fields.
3. Truncated child seller IDs. MCM child IDs run up to 64 characters, and legacy pipelines with shorter column limits clip the sid, so the buyer matches nothing.
4. A complete flag left at 0. Some wrappers default it there. Buyers read 0 as a chain that hides nodes and discount the path even when every visible node validates.
5. Confidentiality applied where transparency sells. An is_confidential flag set to true hides a seller whose name would win the bid. Buyers keep the ID, lose the trust signal, and price accordingly.

What we run, and why the chain follows the auction

We are an ad network, an SSP and an agency in one company. At OnlyMedia we run Google Ad Manager, AdX and MCM for our publisher partners, thousands of them, each above one million monthly pageviews, and we pay Net 30 on CPM terms. In our SSP, one unified auction per impression pulls AdX via MCM, Prebid and OpenRTB seats over managed floors, so the chain we attach reflects the auction that actually ran rather than a summary someone wrote after the fact.

The same posture applies on our other sides. The curated programmatic demand network takes publishers at this scale and pays them on the fixed Net 30 CPM schedule, so a verified chain converts to cash without a reconciliation dispute. Advertisers working with our agency side buy demand reach with verified audiences through curated supply paths over OpenRTB 2.6, and those buyers request schain before they scale spend. Engineering teams integrating directly against us start from our OpenRTB and VAST integration documentation and inspect the exact request envelope before they ship.

Every impression a site above one million monthly pageviews sells travels through at least one intermediary, so a party always signs a chain on your behalf. The distance between 79 percent presence and 42 percent validity is the cheapest available uplift in programmatic right now: it costs a quarterly audit and a request log review, not a fee change. Run the audit, close the five failure modes, and send implementation feedback to IAB Tech Lab before the comment window closes on October 16, 2026.