Buyers

The SupplyChain object (schain) explained

By Stoqlab Research · Updated 6 October 2026 · 6 min read

app-ads.txt and sellers.json describe who may sell an app's inventory. The SupplyChain object, usually called schain, describes who did sell one particular impression. It travels inside the OpenRTB bid request and lists, in order, every seller that handled the request on its way to the buyer.

It is defined by the IAB Tech Lab as the OpenRTB SupplyChain object. In OpenRTB 2.5 it sits at source.ext.schain; from OpenRTB 2.6 it is a regular field, source.schain.

An example

An app sells through its own SSP account, and a reseller passes the request on to a second exchange:

"source": {
  "schain": {
    "ver": "1.0",
    "complete": 1,
    "nodes": [
      { "asi": "ssp.example",      "sid": "4821", "rid": "req-1", "hp": 1 },
      { "asi": "exchange.example", "sid": "7730", "rid": "req-2", "hp": 1 }
    ]
  }
}

The fields

Field	Meaning
`ver`	Required. Specification version, "1.0".
`complete`	Required. 1 if the chain contains every node back to the owner of the app; 0 if some seller did not add itself (or the chain was started by someone who did not support it).
`nodes`	Required. One object per seller, in order: the first is the app's own account in a complete chain, the last is whoever sent this request.
`asi`	Required, per node. The ad system's canonical domain, the same as field #1 in app-ads.txt.
`sid`	Required, per node. The seller account on that system: field #2 in app-ads.txt, `seller_id` in its sellers.json.
`hp`	Required, per node. 1 when the node is in the payment flow. Version 1.0 says it must always be 1.
`rid`	Optional. The request ID as issued by that seller.
`name`, `domain`	Optional, and meant to be left out when the system's sellers.json already has them.

How sellers are supposed to build it

The seller originating the request creates the object with complete: 1 and itself as the only node.
A reseller copies the object, keeps complete as it was, and appends its own node.
A reseller that received no schain creates one with complete: 0 and its own node.
A reseller may not pass the object on without adding itself; if it will not add itself, it must drop the object.

How buyers validate it

Each node can be checked against public files:

First node, complete chain: asi and sid should appear in the app's app-ads.txt, normally as DIRECT, and the seller should be a PUBLISHER in that system's sellers.json whose domain matches the app's OWNERDOMAIN.
Every node: sid should be listed in the asi's sellers.json; nodes after the first are normally INTERMEDIARY.
Every node except the first: its asi and sid should appear in the app's app-ads.txt, normally as RESELLER, since the publisher has to authorise each account that sells its inventory.

Paste a schain into the schain validator to run these checks against the files we hold.

Version 1.1 and hp = 0

The IAB Tech Lab has proposed a version 1.1 that allows hp: 0 nodes for companies that handle a request (SDKs, server-side ad insertion, wrappers) without being in the payment flow. Such nodes are not expected to appear in app-ads.txt, so a validator written for 1.0 will flag them wrongly. Check which version a chain declares before you treat a missing node as an error.

What it cannot tell you

The schain is self-reported by the sellers in it. A node that is listed correctly in every file is authorised, not necessarily honest; and an incomplete chain (complete: 0) leaves the start of the path unknown. The verification guide puts it next to the other checks.

Buyers How to read a supply path Buyers How buyers verify mobile app supply Basics sellers.json explained: fields, seller types and how to read one