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.
2.6-2022042.6-2022102.6-2022112.6-2023032.6-2023092.6-2024022.6-2024092.6-2025012.6-202505
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. OpenRTB 3.0 uses a different request envelope and is not fully wired yet, and bid response validation is on the roadmap.
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.