What is OpenRTB, and which parts should buyers know?
Part of Supply path transparency
The short answer
OpenRTB is IAB Tech Lab's open standard for real-time bidding: the shared format in which exchanges send bid requests and bidders return bids. Version 2.6, published in 2022, now receives dated releases, the latest being 2.6-202606. Buyers should know which of its objects carry the site, the deal terms and the supply chain.
Key takeaways
- OpenRTB is a common language for buyers and sellers, not a rulebook for how each business must operate.
- A bid request is built from nested objects; the impression object is the only one technically required.
- OpenRTB 2.6 added CTV ad pods, moved enumerated lists to AdCOM and made the supply chain and extended IDs formal objects.
- Since November 2022 the 2.6 line gets dated releases, and the version number changes only for breaking changes.
- Many useful fields are only recommended, so what a buyer actually receives depends on each exchange's integration.
What is OpenRTB?
Definition
- OpenRTB
- An open specification from IAB Tech Lab that defines how a seller's system describes an ad opportunity to bidders in real time, and how bidders answer with a bid, plus the notices that follow.
The OpenRTB 2.6 specification (opens in a new tab) states its own goal plainly: to create a lingua franca for communicating between buyers and sellers. It adds that the intent is not to regulate exactly how each business operates, but to make integration easier. In practice that means a demand side platform can read requests from many exchanges with one parser, and an exchange can reach many bidders without a custom format for each.
OpenRTB began in November 2010 as a pilot between three demand side platforms and three sell side platforms, aimed at exchanging block lists. A mobile specification followed in February 2011, and OpenRTB 2.0, released in June 2011, combined display, mobile and video in one document. It became an IAB Tech Lab standard in January 2012 with version 2.1.
| Version | Headline addition |
|---|---|
| 2.0 | Display, mobile and video combined in one specification |
| 2.2 | Private marketplace direct deals, video, mobile and regulatory signals |
| 2.3 | Native ad units |
| 2.4 | Audio ad units and the largest set of minor to moderate enhancements in 2.x history |
| 2.5 | Header bidding support, billing and loss notifications, impression metrics, out-stream video |
| 2.6 | Ad pods for CTV, a structured user agent object and other minor enhancements |
What are the main objects in an OpenRTB bid request?
A bid request is a tree of objects. The specification says that of the top level object's direct subordinates, only Imp is technically required, since it describes the impression being sold, and each Imp needs at least one of Banner, Video, Audio or Native. Everything else, from the site to the supply chain, is there to help bidders make targeting and pricing decisions. The table groups the objects by the question a buyer brings to them.
| Buyer's question | Objects that answer it | Specification summary |
|---|---|---|
| What is for sale? | Imp, with Banner, Video, Audio or Native | The specific impression and the formats the publisher will accept |
| Where will the ad appear? | Site, App or DOOH, with Publisher | The website, app or out of home screen, and the entity that controls it |
| What is the content? | Content and Producer | The published content around the ad and who originally made it |
| On what terms? | Pmp and Deal | Private marketplace deals and their terms for this impression |
| Who handled it? | Source, SupplyChain and SupplyChainNode | Upstream decisioning and the chain of entities paid for the inventory |
| Who will see it? | Device, Geo, User, Data and EIDs | The device, its location and the user data the seller chose to pass |
| Which rules apply? | Regs | Regulatory conditions in effect, such as COPPA and privacy strings |
A line by line reading of one sample request is in the bid request guide. The deal and content objects each have their own field guides: the OpenRTB deal object and the OpenRTB content object.
What changed between OpenRTB 2.5 and 2.6?
The specification's change log lists the substantive differences. Several of them formalized fields that exchanges had been sending in ext, the placeholder for exchange specific extensions, so that every party reads them in the same place.
| Change | What it means for a buyer |
|---|---|
| Ad pod fields for video and audio, such as podid, poddur and slotinpod | CTV ad breaks can be offered and bid on as pods, not only as single spots |
| Network, Channel, SupplyChain, SupplyChainNode, EIDs and UIDs added as objects | The supply chain and extended IDs have formal places instead of extensions |
| cattax used for all taxonomy references | Category codes declare which IAB Tech Lab taxonomy they come from |
| Enumerated lists removed and pointed to AdCOM 1.0 | Value lists, such as ad positions or devices, are looked up in AdCOM |
| gdpr in Regs and consent in User, previously in ext | Privacy signals arrive in standard fields |
| language field supporting IETF BCP 47 | Language can be declared more precisely, for example by written variant |
| Previously deprecated attributes removed, more deprecated | Old fields such as yob and gender in User are deprecated and should not be relied on |
The bigger change came after 2.6 was published. According to the OpenRTB 2.x repository (opens in a new tab), as of 2.6-202211 the version number is incremented only on breaking changes, and non breaking improvements are released roughly monthly with a date code, such as 2.6-202211 for November 2022. The releases page (opens in a new tab) shows what each one added: a DOOH object and the GPP privacy string (2.6-202211), the Refresh object and the plcmt video field (2.6-202303), gtax and genres in Content with Content Taxonomy 3.1 (2.6-202501), and realtime and firstbroadcast attributes in Content (2.6-202606, released June 11, 2026).
Which OpenRTB fields should a media buyer know?
A planner may never read raw requests, but the fields below decide whether a site list, a deal or a supply path rule can work at all. They are the ones worth asking a trading desk or platform to show in log samples.
Fields a buyer should be able to see for any planned site
- site.domain and site.page name the site and page, which site lists and context checks are matched against.
- site.publisher.id carries the seller ID, which should match a seller_id in the exchange's sellers.json file.
- site.inventorypartnerdomain, where present, names a content owner authorized to monetize part of the site's inventory.
- imp.pmp.private_auction and each Deal's id, bidfloor and at show whether the impression is offered only under a deal and on what price terms.
- source.schain lists every node that handled the request and whether the chain is complete.
- source.tid and source.fd show a transaction ID shared across exchanges and who makes the final sale decision.
- regs.coppa and the gpp string show the regulatory conditions the seller says apply.
The supply chain fields have their own guide, the supply chain object, and the deal fields connect to the deal ID guide.
Where can buyers read the OpenRTB specification?
IAB Tech Lab publishes OpenRTB on GitHub, and the specification is licensed under a Creative Commons Attribution 3.0 License, so anyone can read it without a membership. The repository's main branch always reflects the most recent release, while ongoing work happens in a separate develop branch.
How to look up a field in five steps
- Open the 2.6 document. The file 2.6.md in the openrtb2.x repository holds every object and attribute with its type and description.
- Check the value list in AdCOM. As of OpenRTB 2.6, enumerated lists live in the AdCOM repository (opens in a new tab), so codes such as taxonomy IDs are defined there.
- Read the implementation notes. The implementation notes (opens in a new tab) explain deals, pod bidding, floors and how to count billable events.
- Find when the field arrived. The releases page dates each addition, which tells a buyer whether an older integration can carry it.
- Ask the exchange for its extensions. The specification says exchanges using ext objects are responsible for publishing their extensions to their bidders.
OpenRTB 3.0, first released in November 2018 and last revised in March 2022 according to the version history in its own repository (opens in a new tab), is a separate layered design that moves the description of ads into AdCOM. It is not an update to 2.6, and the 2.x line keeps receiving dated releases. The 2.x repository also notes that an OpenRTB 2.7 should be considered a distinct version from 2.6, so a buyer reading a request should check its x-openrtb-version header, which the specification asks senders to include so a receiver knows the version before parsing.
What does an OpenRTB check look like on a real plan?
Fictional example
An activewear brand in Honolulu and Maui
A fictional activewear brand based in Honolulu wants ads beside yoga, gym training and fitness content read in Hawaii, in English, on websites and in CTV apps. Before approving the plan, the trading desk asks its two main exchanges for sample bid requests on the planned sites.
One exchange's samples carry x-openrtb-version 2.6, with the supply chain in source.schain and content language filled in. The other exchange sends 2.5 requests with the supply chain inside an extension, and its CTV samples offer single spots rather than pods. The desk asks the second exchange for its extension documentation before setting supply chain rules, so that a complete chain is not mistaken for a missing one.
Several website samples arrive without site.page, only the domain. The planner notes that page level checks cannot run on those requests and keeps them on the domain list, rather than treating a missing recommended field as a sign of bad inventory.
How does PlacementGraph prepare the site side before any bid request?
Frequently asked questions
Is OpenRTB only used for display ads?
No. OpenRTB 2.x covers banner, video, audio and native impressions, and the 2.6 line added ad pods for connected TV and a DOOH object for digital out of home screens. The same request structure carries all of them, with the Imp object saying which formats the seller will accept for each impression.
What is AdCOM, and why does OpenRTB point to it?
AdCOM, the Advertising Common Object Model, is a companion IAB Tech Lab specification that defines objects and value lists shared across several standards. As of OpenRTB 2.6 all enumerated lists are kept in AdCOM, which lets IAB Tech Lab update values, such as category taxonomies, faster than the main specification.
Will there be an OpenRTB 2.7?
Only if a breaking change is needed. Under the versioning policy adopted with 2.6-202211, new fields and values arrive as dated 2.6 releases, and the version number moves only when a change would break existing integrations. The specification asks bidders and exchanges to tolerate new or unexpected fields gracefully in the meantime.
Do bidders have to upgrade to each monthly release?
No. The specification says neither party needs to explicitly negotiate an upgrade to the latest release. Exchanges should start sending a new field once they choose to support it, and bidders can start reading it when it is relevant to them. Partners discuss specific fields of interest as they become available.
Sources
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab, OpenRTB 2.x repository
- OpenRTB 2.x repository and versioning policy (opens in a new tab)IAB Tech Lab on GitHub
- OpenRTB 2.x releases (opens in a new tab)IAB Tech Lab on GitHub
- OpenRTB 2.6 implementation notes (opens in a new tab)IAB Tech Lab, OpenRTB 2.x repository
- AdCOM: Advertising Common Object Model (opens in a new tab)IAB Tech Lab on GitHub
- OpenRTB repository, including OpenRTB 3.0 (opens in a new tab)IAB Tech Lab on GitHub
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.