RTBlintAlpha

Docs

OpenRTB versions

OpenRTB is not a single frozen document. The 2.x line has shipped continuous revisions, and a field can be added, deprecated, moved, or removed between them. RTBlint tracks those revisions as dated snapshots so the result matches the version you actually run.

Why snapshots, not just 2.6

Calling a request OpenRTB 2.6 is not precise enough. Between the 2.6 revisions, fields such as the GDPR signal moved out of an ext block and onto a first-class path. Validate against the wrong revision and you either miss a moved field or flag one that is correct for your partner. A dated snapshot pins the exact rule set.

Tracked 2.6 snapshots

The tester defaults to the latest snapshot. Pick an earlier one to validate against the revision your exchange or bidder is on.

Every tracked version

Each version has its own page: what it added, deprecated, moved, or removed, plus a JSON Schema and a validator pinned to that revision.

Earlier 2.x and 3.0

RTBlint ships an object catalog for every tracked version, 2.0 through 3.0, so undefined-field and type checks work across the whole line, and each version carries a profile describing what that release changed. Rule depth (deprecations, moves, and the semantic checks) is richest on the tracked 2.6 snapshots. Bid responses validate on every version too, standalone or against the request they answer. OpenRTB 3.0 wraps everything in an openrtb envelope and validates through it: the transport objects are checked in full, and so are the AdCOM objects under item.spec, bid.media, and request.context.

See what RTBlint checks for the categories, or the rule reference for the ids that fire when a field is deprecated, moved, removed, or not yet available in the selected snapshot. Every version also has a downloadable JSON Schema generated from the same catalogs.