What is SupplyChain Object (schain)?

The SupplyChain object (schain) is an OpenRTB field in a bid request that lists every party that sold or resold that impression, one node per hop, so buyers can trace the path back to the inventory owner.

Also known as: schain, SupplyChain object

How it works

When an impression is sold programmatically, it may pass through more than one company before it reaches a buyer. A publisher's SSP might sell it directly, or an intermediary might resell it through another exchange. Each of those handoffs is a hop. The SupplyChain object, usually shortened to schain, adds a record of every hop to the bid request itself, so the buyer can see the whole route rather than just the last seller.

The specification describes the object with a few top-level fields and a list of nodes (SupplyChain object specification):

  • complete: 1 if the chain goes all the way back to the inventory owner, 0 if not.
  • ver: the version of the specification in use.
  • nodes: an ordered list, one node per party that sold or resold the impression.

Each node carries:

  • asi (required): the canonical domain of the advertising system, such as the SSP or exchange.
  • sid (required): the seller or reseller account ID within that system.
  • hp (required): whether this node is part of the payment flow.
  • rid, name and domain (optional): the request ID that node issued, and the seller's name and domain. Name and domain are usually omitted because buyers can find them in sellers.json.

In OpenRTB 2.6 and later, the object sits in the source object of the bid request; older versions carried it in an extension field.

Why it matters

Without a record of every hop, a buyer cannot tell a direct path from one that passes through several intermediaries before it arrives. The SupplyChain object makes that path visible.

How do buyers use it?

The schain becomes powerful when it is checked against the other two transparency standards. The asi and sid in each node should match a record in the publisher's ads.txt file, and the sid should match a seller_id in that system's sellers.json. When everything lines up, the buyer can see who handled the impression and whether each party was authorized. The specification says the object is meant to help buyers verify intermediaries and favour more direct purchases, which is why it is a core input to supply path optimization.

Example

Example (illustrative)

A buyer receives a bid request for a cooking site with a complete schain of two nodes. The first node is a reseller account on one exchange, and the second is that exchange's account on another exchange, which sent the request to the buyer. The buyer checks the site's ads.txt and finds the first account listed as RESELLER, then looks up both seller IDs in the exchanges' sellers.json files. Everything matches, but the buyer also sees a one-hop direct path for the same site elsewhere and decides to prefer that one.

IncrementX perspective

The schain makes every extra hop visible, so representation choices show up directly in what buyers see. Shorter, clearly authorized paths tend to be easier for buyers to trust. When IncrementX represents a publisher's inventory through media representation and connects it with demand through the Demand Marketplace, keeping ads.txt, sellers.json and schain data consistent helps that inventory hold up under buyer scrutiny.