Schain Validator
Validate a Prebid or OpenRTB supply chain object by checking version, complete flag, node count, and missing `asi` / `sid` / `hp` fields. This is useful during supply-path reviews, reseller onboarding, or anytime a team needs to explain how a supply chain should look before it reaches bidders.
Validate the supply chain object before a bidder, SSP, or reseller review turns messy.
What you can do here
- Validate a new reseller onboarding setup.
- Review supply-path transparency before launch.
- Check whether a schain object looks complete during debugging.
Before you start
- Paste a schain object or containing config.
About Schain Validator
The Schain Validator checks the structural basics of a supply chain object so teams can confirm version, completeness, and node hygiene before they escalate a supply-path issue.
Use it during onboarding, audits, or any workflow where schain needs to be checked separately from the rest of the page config.
Best uses for Schain Validator
- Validate a new reseller onboarding setup.
- Review supply-path transparency before launch.
- Check whether a schain object looks complete during debugging.
How to use Schain Validator
- Paste a schain object or a config snippet that includes one.
- Inspect version, complete flag, and node fields.
- Use the warnings to clean up missing or suspicious hops.
What to paste in
- Paste a schain object or containing config.
What you should see
- Parsed nodes, structural findings, and validation warnings.
Example checks
These are simple checks you can run when you want a real sample and a clear result to compare against.
Paste a schain object or containing config.
Why run it: Validate a new reseller onboarding setup.
What to look for: Parsed nodes, structural findings, and validation warnings.
Supply Chain Objects Need Operational Review, Not Just Spec Awareness
Why schain validation matters
Supply chain objects are meant to make the reseller path more transparent, but in day-to-day debugging they are often treated as invisible metadata. That is a mistake. If the schain is malformed, incomplete, or unexpectedly deep, bidders and partners may see a different supply-path story than the publisher expects. During audits and onboarding, that can create friction that is hard to explain if nobody has reviewed the object directly.
A schain validator is useful because the object is simple enough to inspect quickly but important enough to deserve a repeatable check. Version, complete flag, node count, and the presence of required node fields are straightforward validation targets. Teams should not have to eyeball raw JSON or JS objects manually every time this comes up.
This also fits cleanly into the header bidding cluster because schain is frequently handled alongside Prebid configuration and bidder troubleshooting. It is part of the same operational picture even if it is not always the first thing teams think to inspect.
What good schain review looks like
The first step is structural hygiene: confirm that version and complete are present and that each node has the fields the receiving systems expect. Then comes hop review. How many nodes are visible? Do they appear plausible for the business relationship being represented? Even without making commercial judgments, unusually deep or incomplete chains are worth flagging early.
This is valuable in both onboarding and incident response. During onboarding, it helps prevent avoidable back-and-forth with partners. During debugging, it helps teams rule structural issues in or out quickly. A missing `asi`, a blank `sid`, or a malformed node is exactly the sort of thing that should be surfaced before the conversation drifts into vague supply-path speculation.
In practice, the best schain reviews are short and specific. The object is fine or it is not. The validator exists to make that answer easier to reach.
Why a dedicated schain page can win niche intent
A general header bidding guide will mention supply-path transparency, but that is rarely enough for someone who is actively trying to validate a schain object. They want a focused workflow and a tool that maps directly to the job. That is the kind of long-tail intent a specialized site can realistically serve.
This is also why schain content works well as part of a broader library strategy. It connects to onboarding, reseller review, Prebid config, and supply-path audit topics without competing directly on a broad keyword like 'Prebid.' The value is in solving a narrow, real debugging task.
Operationally, that narrow focus is exactly what teams need. The faster they can validate schain structure, the faster they can decide whether the object is part of the problem or simply part of the context.
Troubleshooting
What to look for
- Parsed nodes, structural findings, and validation warnings.
Common issues
- A structurally valid schain can still be commercially wrong.
- If the schain is generated dynamically, a partial paste may not show the full object.
Best practices
- Paste raw input so the tool can apply formatting consistently.
- If output looks wrong, validate the input for missing commas or tags.
- Use the example buttons above to sanity-check formatting and behavior.
Related tools
More tools in the header bidding category.
- Prebid Timeout Risk Analyzer - Diagnose Prebid auction timeout risk from real config snippets, adUnits, and optional bidder timing notes. Instead of only guessing from fetched HTML, the tool inspects timeout settings, auction pressure, identity delay markers, and pasted bidder outcomes so teams get a more actionable first-pass readout of why bids may be missing the auction.
- Prebid Config Inspector - Inspect a Prebid `pbjs.setConfig` snippet and surface the auction settings that actually shape runtime behavior: bidder timeout, timeout buffer, consent modules, user sync, floors, S2S, and more. This tool is built for engineers and ad-ops teams who need a fast readout of whether a configuration is sane before they open devtools or live auction logs. Paste a real config block and get concrete findings instead of guessing which modules are active.
- Prebid Ad Unit Inspector - Parse a real `adUnits` snippet and break it down into ad-unit codes, media types, sizes, bidder counts, and duplicate patterns. This is useful when a page looks overloaded, when bidders are attached to the wrong unit, or when teams need to understand the auction shape quickly before debugging runtime issues. It focuses on the ad-unit layer instead of the broader page shell.
- Prebid User ID Inspector - Inspect Prebid `userId` and `userSync` configuration to see which identity modules appear active, what storage types they use, whether consent markers are visible, and whether auction delay settings look aggressive. This gives teams a real first-pass identity and sync review that is specific to header bidding rather than generic privacy tooling.
Related reading
More specific pages for the exact jobs this tool supports.
Validate Schain Before a Reseller Review
A narrow supply-chain workflow for Prebid and OpenRTB transparency checks.
Find Missing Schain Node Fields Before Onboarding
A narrow pre-onboarding workflow for schain field hygiene.
Check Schain Depth Before a Supply-Path Audit
A hop-depth workflow for schain review.
Validate Schain in a Prebid Config Snippet
A config-embedded schain workflow for implementation review.
Review Schain Complete Flags Before Bidder Certification
A certification-prep workflow for schain completeness signals.
Check Schain Node Order Before a Reseller Audit
A node-order workflow for schain audit preparation.
Frequently asked questions
Is it free to use?
Yes. Core tools are free and accessible without signup.
Does it upload my data?
This tool runs locally in your browser. Data you paste or files you upload stay on your device and are not uploaded.
What if I spot a bug?
Please reach out via the Contact page with a reproduction example.
Does it verify business correctness?
No. It validates visible structure, not whether the commercial relationships are right.
Can it read a full config block?
Yes, as long as the schain object is present in the pasted text.
Why is this useful in header bidding?
Because supply-path transparency is often debugged alongside Prebid config and bidder behavior.
Helpful links
Standards & references
Official specs that inform how this tool interprets data.