OpenRTB 2.6-202505: what changed and what to do about it

What actually shipped

The GitHub release notes for tag 2.6-202505 list four items. Read against the current 2.6.md spec text, they break down like this:

• Addition of cids to the Data object (Section 3.2.21). A new attribute, type string array, on the same Data object used for segment and data-provider entries attached to user.data or content.data.
• Implementation guidance for Extended Content Identifiers, added as a new Section 7.14 in the companion implementation guide.
• Deprecation of the Extended Content Identifiers community extension that bidders previously used as a stopgap before this became a first-class field.
• An updated content.id description in the Content object (Section 3.2.16), plus an errata fix changing genres from an integer array to a string array so genre IDs can include letters.

The new field: data.cids

The spec defines cids as: "An array of Extended Content IDs, representing one or more identifiers for the video or audio content from the ID source specified in the name field of the data object." It lives on the Data object, not on Content directly, so the full path in a bid request is content.data[].cids (or user.data[].cids if a data provider is attaching content IDs to user-level data instead).

The implementation guide explains the problem this solves. A content data platform aggregates video or audio metadata from publishers and assigns each piece of content an ID unique within that platform, an "Extended Content ID." A publisher passes that ID and its source through the bid request; a contextual data vendor on the buy side uses it to look up classifications for the same content without the exchange needing to broker that metadata directly. Before 2.6-202505, exchanges did this through a community extension. The new field standardizes it.

Two rules from the spec text are worth calling out directly, since they are easy to get wrong:

• cids should only ever carry the external system's content ID. The guide is explicit that passing anything else is discouraged.
• cids is not for genre or category classification. That is still content.genres and content.cat. Extended Content IDs identify one piece of content; they are not taxonomy values.

The provider or source of a given Extended Content ID is expected to pick a root domain it owns and consistently identify itself that way in the name field, similar to how bidder namespaces work elsewhere in the spec. The implementation guide's JSON example shows the shape:

{
  "app": {
    "content": {
      "id": "video_123",
      "data": [
        {
          "name": "vendorA.com",
          "cids": ["vendorA_c73g5jq96mwso4d8"],
          "segment": [
            { "id": "context_5784065" },
            { "id": "context_5711828" }
          ]
        }
      ]
    }
  }
}

Multiple vendors can appear as separate entries in the data array, each with its own namespaced cids values pointing at the same underlying content.

The two smaller corrections

content.id now reads simply: "Publisher-provided ID uniquely identifying the content." The clarifying note added alongside the cids work is that content.id is for the seller's own content ID, while IDs from external content classification services belong in content.data[].cids, namespaced by vendor. Mixing the two, for example putting a third-party content-platform ID into content.id, defeats the point of having a separate field.

content.genres changed type from integer array to string array. This is an errata correction, not a new field: the taxonomy IDs it points to already contain letters, so an integer-only type was wrong. Any strict schema validation that assumed genres was numeric will need updating regardless of whether an organization touches Extended Content Identifiers at all.

What this means for exchanges and bidders

None of this changes required fields or breaks existing requests: cids is additive, and the other two changes are documentation and type corrections rather than behavior changes. The integration work is mostly on the reading and validating side:

• Exchanges that already pass content IDs through a proprietary or community-extension field should plan a move to content.data[].cids, since the community extension it replaces is now marked deprecated in the spec.
• Bidders with contextual data vendors should check whether their JSON schema or request parser recognizes cids as a valid attribute on the Data object. A schema that rejects unknown fields will drop it silently rather than error, which is the failure mode worth testing for.
• Anyone validating content.genres against a numeric type needs to widen that check to strings, or validation will reject legitimate alphanumeric genre IDs.

rtblint's own catalog tracks the data.cids addition as of this writing (rule openrtb.2.6-202505.data.cids), which flags the field as a documented 2.6-202505 addition when it appears in a request. It does not yet carry separate rules for the content.id wording change or the genres type correction, since neither introduces a new field to check for.

What to check this week

Run a sample content-heavy bid request, ideally one with content.data entries from a contextual vendor, through the browser tester to see whether cids parses and whether your existing fixtures still validate under the current dated snapshot. If you run validation in CI, the Rust CLI checks the same rules against a request file:

rtblint validate request.json

For the full list of what each dated snapshot changed since 2.6-202211, see the dated snapshots explainer, and for every rule rtblint currently checks, browse the rule catalog.

Sources

• OpenRTB 2.6-202505 release notes, GitHub (InteractiveAdvertisingBureau/openrtb2.x)
• OpenRTB 2.6 specification text, Section 3.2.21 (Object: Data) and Section 3.2.16 (Object: Content)
• OpenRTB implementation guide, Section 7.14, Using Extended Content Identifiers