Docs
RTBlint documentation
How RTBlint validates OpenRTB bid requests, what each finding means, and how to run the same checks from the tester, the Rust core, or the CLI.
What RTBlint checks
RTBlint validates an OpenRTB bid request or bid response against a tracked snapshot of the specification. It is a structural and semantic linter, not a schema-only check: it parses the JSON, walks the object tree against the canonical OpenRTB catalog, and reports anything that does not belong, is in the wrong place, or has the wrong type, plus a semantic rule pack for cross-field checks the catalog alone cannot express.
OpenRTB 3.0 validates through its layered envelope: the transport objects (Openrtb, Request, Item, Deal, Source, Response, Seatbid, Bid) and the AdCOM 1.0 domain objects under item.spec, bid.media, and request.context. A 2.x payload sent to a 3.0 validator gets a diagnostic naming where each object moved.
Rule ids
Every issue carries a stable rule id and, where it applies, the JSON path that tripped it. The id is the contract: it does not change when wording changes, so you can match on it in CI. A representative sample is below; see the full rule reference for every id RTBlint emits.
openrtb.payload.invalid_jsonerrorThe payload is not parseable JSON. No field rules run until this is fixed.openrtb.field.undefinederrorA field is not defined in the canonical OpenRTB catalog for the selected version.openrtb.field.deprecatedwarningA field still parses but is deprecated in the selected version. Migrate to its replacement.openrtb.field.movederrorA field moved to a different path in this version (for example regs.ext.gdpr → regs.gdpr).openrtb.schain.node.hp_missingwarningA SupplyChain node has no hp field; the spec expects it to be propagated on every node.openrtb.native.request.double_encodederrornative.request parses to another JSON string rather than an object: it was JSON-encoded twice.openrtb.request.tmax_implausiblewarningtmax is unusually high for an RTB auction; likely seconds instead of milliseconds.OpenRTB protocol reference
Beyond the validator, the docs cover the protocol details that usually live in the spec PDF: object anatomy, enumerated lists, privacy signals, and the fields that changed between versions.
- OpenRTB bid request: objects and required fields
- OpenRTB bid response: seatbid, bid, and win notices
- OpenRTB enumerated lists reference
- Privacy signals in OpenRTB: gdpr, gpp, us_privacy, coppa
- OpenRTB supply chain object (schain)
- AdCOM 1.0 object reference: media, placement, context
- Native ads in OpenRTB
- OpenRTB Video object: every field, grouped by what it controls
- video.plcmt in OpenRTB: values, versions, and what buyers filter on
- OpenRTB Audio object: podcast and streaming audio bid requests
- CTV in OpenRTB: video object, ad pods, plcmt
- tmax in OpenRTB: auction timeouts explained
- Bid floors in OpenRTB: bidfloor and bidfloorcur
- OpenRTB substitution macros
Tracked versions
RTBlint tracks OpenRTB 2.6 by release snapshot (2.6-202204 through 2.6-202606) so that deprecations and moved fields are reported against the exact version you target. The tester defaults to the latest 2.6 snapshot; pick an older one to validate against it.
Run it yourself
The tester is the RTBlint Rust core compiled to WASM. The same core is available as a library and CLI:
- Rust:
rtblint-coreand thertblintCLI on crates.io - CLI:
rtblint validate request.jsonorrtblint validate --stdin
Start with the bid request tester to see the output shape, then wire the same checks into your pipeline.