> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.pixalate.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.pixalate.com/_mcp/server. # SCO validation and verification > What the OpenRTB SupplyChain object (SCO) is, how Pixalate validates its structure and verifies each node against ads.txt, app-ads.txt and sellers.json, why it matters, and a glossary of SCO terms. The SupplyChain object (SCO) is part of the OpenRTB bid request. It lists every entity involved in selling an ad impression, from the publisher through each seller and reseller. Pixalate checks SCOs in two ways: **validation** confirms the SCO is well formed, and **verification** confirms that each seller it declares is authorized. You can run these checks per bid request with the [SCO Validation & Verification API](/apis/sco-api), or review them across your traffic in the [Analytics SCO reports](/analytics/sco-reports). *Video (2 min): how SCO validation differs from verification.* ## What the SupplyChain object is The SCO is an IAB Tech Lab supply chain transparency standard. It works alongside two other IAB Tech Lab standards, **ads.txt** (and **app-ads.txt** for apps) and **sellers.json**, to show who is involved in selling the inventory in a bid request. An SCO is made up of a set of **nodes**. Each node represents one entity that takes part in selling the ad placement. The full chain, from first node to last, represents every entity involved in the direct flow of payment for the inventory. Each node has two required properties: * **`asi`** (advertising system identifier): the domain name of the advertising system. * **`sid`** (seller ID): identifies the seller of the inventory, that is, who the advertising system pays for it. The `asi` and `sid` should be the same values the publisher lists in its ads.txt or app-ads.txt file. A seller ID must map to only one entity that is paid for inventory sold with that ID. One selling entity can have several seller IDs within an advertising system. The SCO also carries chain-level fields, including its version (`ver`) and a `complete` flag that declares whether the chain is complete. ## Validation and verification | Check | What Pixalate confirms | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Validation** | The SCO's structure is correct: it can be parsed and contains all required fields. | | **Verification** | The data in the SCO is accurate and legitimate. Pixalate checks each node against the corresponding ads.txt, app-ads.txt and sellers.json entries. | Verification checks each node against two sources: 1. **sellers.json:** for each node, the upstream node matches the seller's sellers.json entry. 2. **ads.txt or app-ads.txt:** for each node, the publisher has authorized that seller. The first seller must be listed as `DIRECT`, and the sellers after it as `RESELLER`. When a check fails, Pixalate reports a reason or error code. See [SCO error and reason codes](/compliance/sco-error-codes). ## Why verification matters Ad supply chains involve many sellers and resellers, which makes them hard to understand. The SCO was designed to bring transparency, but it can also be faked, and without verification that goes unnoticed. Verifying SCOs helps you: * **Improve SCO structural quality** by finding SCOs that are malformed or incorrect, and fixing them. * **Find unauthorized sellers and resellers**, entities attempting unauthorized ad arbitrage, and block them. * **Find inaccurate chain relationships** and block those sellers. * **Find potentially spoofed impressions**, where an entity sells impressions from one source while claiming they come from a more valuable one. * **Reduce IVT.** Pixalate has observed higher invalid traffic (IVT) rates on SCOs that fail validation or verification. ## Where to use it | Tool | Use it to | Learn more | | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | | SCO Validation & Verification API | Check one SCO, or many in bulk, before you act on a bid request. Returns a status and reason codes. | [SCO Validation & Verification API](/apis/sco-api) | | Analytics SCO reports | Review supply chain performance across your domains, mobile apps and CTV apps, broken down by node, seller, chain length and reason code. | [Supply chain (SCO) reports](/analytics/sco-reports) | To send the SCO to Pixalate through the Analytics tag, see [The Pixalate tag and macros](/analytics/tag-and-macros). ## Glossary ### Supply chain object (SCO) The OpenRTB SupplyChain object: a set of nodes, each representing an entity that takes part in selling an ad placement. The full chain represents every entity involved in the direct flow of payment for the inventory. ### Node One entity in the SCO. A node has two required properties: the advertising system identifier (`asi`) and the seller ID (`sid`). ### sellers.json A published, accessible file that lets buyers discover the entities that are either direct sellers of, or intermediaries in, the sale of its inventory. Verification checks that, for each node, the upstream node matches the sellers.json entry. ### ads.txt and app-ads.txt Files publishers publish to declare which entities are authorized to sell their inventory: ads.txt for websites, app-ads.txt for apps. Verification checks that, for each node, the publisher has authorized that seller. ### SCO validation Confirming the SCO's structure is correct: it can be parsed and contains all required fields. ### SCO verification Confirming the data in the SCO is accurate and legitimate, by checking each node against the corresponding ads.txt, app-ads.txt and sellers.json entries. ### Seller In the Analytics SCO reports, the numeric ID of the partner you're buying supply from. It's passed in a separate macro, not in the SCO, so it's different from a node's seller ID (`sid`). ### Seller type The position an entity holds in the SCO. For example, the developer of an app is shown as `PUBLISHER`, and a seller or reseller as `INTERMEDIARY`. ### Seller domain The owner domain of the publisher, seller or reseller listed in the SCO. For example, an app by a developer whose website is `example.com` has the seller domain `example.com`. ### Valid chain An SCO in correct OpenRTB format, with all nodes and correct IDs included, that is declared complete. In the Analytics SCO reports, a **Valid SCO** is a complete chain in which every node passed with the correct seller and advertising system IDs, and each entity has the correct seller type. ### Incomplete chain An SCO with a node missing or not passed correctly. An SCO without the complete flag is also marked incomplete. ### Reason and error codes The codes Pixalate reports when an SCO fails validation or verification, for example when the chain is incomplete or a node is missing. More than one code can apply to the same SCO. See [SCO error and reason codes](/compliance/sco-error-codes). ### Direct seller not authorized The first seller in the SCO isn't listed as a `DIRECT` seller in the publisher's ads.txt or app-ads.txt. ## Related #### [SCO error and reason codes](/compliance/sco-error-codes) What each validation and verification code means, and what to do. #### [SCO Validation & Verification API](/apis/sco-api) Check SCOs in real time, one at a time or in bulk. #### [Supply chain (SCO) reports](/analytics/sco-reports) Analyze supply chains across your traffic in the Analytics dashboard. Questions? Email [support@pixalate.com](mailto:support@pixalate.com).