- First introduced in 2013, OpenRTB is the universal language of real-time ad auctions for both the buyers and sellers.
- A structured bid request is sent by an SSP and a bid response is returned by DSPs.
- Inventory, device, site or app, geography, user signals, floors, and auction rules can all be described in bid requests.
- OpenRTB 2.6 is the active 2.x release line, while OpenRTB 3.0 saw limited market adoption.
- The same protocol can carry private marketplace and Deal ID information.
- BidsCube uses OpenRTB-based connections across its programmatic trading products.
Table of Contents
A programmatic auction might be concluded before someone sees the page has loaded. That only works because the seller and buyer have reached a mutual understanding on how to represent the impression of the auction and bid.
The OpenRTB protocol provides that shared structure.
IMARC Group now values the global real-time bidding market at $22.3 billion in 2025 and expects it to reach $95 billion by 2034. North America accounted for 42.5% of the market.
To those asking what is OpenRTB, the short answer is straightforward: it is the spec by the IAB Tech Lab that carries auction data from programatic buyers to sellers over the wire.
What Is OpenRTB?
OpenRTB is an open spec for the seller-buyer communication that exists between the sellers of digital ad inventory and the buyers who bid on that inventory. An ad exchange can use it to send real-time bidding (RTB) data between an SSP and a DSP.
According to the purpose statement of IAB Tech Lab, it is to try to create a common language between exchanges, SSPs, DSPs, and other bidders. This project was started in 2010 and became an IAB standard in 2012.
Without a shared specification, one SSP might call a device field device_type, another might use dev, and a DSP would need separate parsing logic for every partner.
The OpenRTB protocol format gives those systems agreed objects, fields, and meanings.
It doesn’t choose which of the advertisers should win the auction. It shows the systems how to propagate the data needed to make that decision.
For a shorter reference, see the BidsCube OpenRTB glossary.
Why OpenRTB Was Created
Early programmatic platforms used many proprietary connection formats. Every new SSP–DSP partnership could require custom engineering.
OpenRTB reduced that problem.
The specification created shared structures for bid requests, bid responses, inventory types, devices, auction rules, deals, and notifications. An integration still needs testing, but engineers do not have to invent the transaction language from zero.
That is the practical meaning of OpenRTB explained: it is less about one auction algorithm and more about letting independent ad platforms understand each other quickly.
Read What Is RTB? for the auction process around the protocol.
What Is Inside an OpenRTB Bid Request?
An OpenRTB bid request describes an impression that may be available for purchase.
The exact fields depend on the inventory and implementation. Common objects include:
imp
Describes the impression. It can contain banner, video, audio, or native information, along with floor pricing and other placement data.
site or app
Identifies the web or app environment associated with the request.
device
Can describe browser, operating system, device type, connection, and other technical information.
geo
Carries permitted geographic information.
user
Can contain user-related IDs or segments when available and permitted.
at
Signals the auction type. In OpenRTB 2.6, 1 means first-price and 2 means second-price.
Not every optional field appears in every request. IAB Tech Lab specifically recommends that partners agree on which fields the seller sends and which fields the buyer needs for decision-making.
See the BidsCube Bid Request glossary and Bidstream Data guide for more detail.
Read the Auction Data
Bidstream fields can show what inventory is entering the auction and why a DSP bids, passes, or rejects a request.
What Does the DSP Send Back?
A DSP that wants the impression returns a bid response.
Common fields include:
price
The CPM bid submitted for the impression.
adm
The advertising markup or creative information returned with the bid.
seatbid and seat
Identify the buyer seat associated with one or more bids.
nurl
A win-notification URL.
burl
A billing-notification URL tied to a billable event.
The response can also include campaign, creative, advertiser, Deal ID, and other information required by the seller.
The BidsCube Bid Response glossary covers the buyer side in more detail.
How an OpenRTB Auction Works
The full exchange usually follows a short sequence.
- A person opens a website or app with available ad inventory.
- The publisher-side system passes the impression to an SSP or exchange.
- The SSP creates a bid request.
- Connected DSPs receive the request and decide whether they want the impression.
- Interested DSPs return a price and creative information.
- The auction compares eligible bids under its pricing rules.
- The winning creative returns through the ad-serving path.
- Reporting and billing signals record what happened.
This second use of OpenRTB bid request matters because bad request data can stop the auction before price becomes relevant. A missing format, incorrect field, or unsupported extension may lead a DSP to return no bid.
OpenRTB 2.5, 2.6, and 3.0
OpenRTB has changed as programmatic media added new formats and transaction methods.
| Version | Main Additions | Current Position |
| OpenRTB 2.5 | Header bidding support, billing and loss notices, flex ads, payment IDs, impression metrics | Still appears in older integrations |
| OpenRTB 2.6 | CTV ad pods, structured user-agent data, added CTV and newer inventory fields | Active 2.x release line |
| OpenRTB 3.0 | New transaction structure used with AdCOM and signed-request concepts | Limited adoption |
IAB Tech Lab states that OpenRTB 2.6 added CTV-related features and remains the active 2.x line.
OpenRTB 3.0 took a different route. It separated the transaction specification from AdCOM, the common advertising object model. IAB Tech Lab later stated that OpenRTB 3.0 was not widely adopted, while AdCOM lists became widely used with OpenRTB 2.x.
The OpenRTB protocol format therefore continues to change mostly through the 2.6 release line and related specifications rather than through a broad move to version 3.0.
How OpenRTB Handles PMP and Deal ID Transactions
Open auctions are only one use case.
OpenRTB 2.6 includes a pmp object. Inside it, a deals array can carry one or more private deal terms. The Deal object can include the Deal ID, floor, auction type, and permitted buyer seats.
This lets an SSP tell the DSP that an impression belongs to a private agreement.
The DSP checks whether its campaign has the matching Deal ID. If it does, the buyer can bid under those deal rules.
Read the BidsCube guides to Private Marketplace and Deal ID for the commercial side.
The same auction-type field can also distinguish pricing rules. See the BidsCube Second-Price Auction glossary for that distinction.
OpenRTB vs Custom Protocols
A proprietary protocol can work well between two systems built specifically for each other. The problem appears when either platform needs twenty, fifty, or several hundred partners.
Custom connections mean more mapping, testing, documentation, and maintenance.
OpenRTB gives engineers a common starting point.
The second OpenRTB protocol advantage is partner portability. A DSP that already understands standard OpenRTB objects can add a new SSP without rebuilding its bidder around a completely different data model.
Extensions still exist. Partners also interpret optional fields differently. A version number by itself does not prove full compatibility.
That is why integration testing remains necessary.
How BidsCube Can Help
BidsCube uses OpenRTB-based programmatic connections across its trading products.
The BidsCube DSP receives auction traffic from supply partners and supports campaign bidding, targeting, bidstream access, and reporting. Current BidsCube technical content identifies OpenRTB 2.6 as the current 2.x baseline for DSP connections.
The BidsCube SSP connects publisher inventory with demand through several connection types, including programmatic integrations, header bidding, tags, and SDK-based paths. BidsCube product documentation also lists oRTB connections for sell-side and exchange endpoints.
This second OpenRTB reference matters during partner onboarding. Version support alone is not enough. Teams should compare required objects, extensions, auction types, native specifications, notification methods, and QPS rules.
BidsCube does not publish a fixed public timetable for adopting every new OpenRTB field. Integration teams should confirm supported versions and extensions during technical onboarding rather than assume every optional field is active.
Independent client feedback is available through the BidsCube Clutch profile.
Final Thoughts
OpenRTB explained in practical terms comes down to one idea: buyers and sellers need to describe the same auction in the same language.
The protocol carries the impression details to buyers and their bids back to sellers. Newer releases have added support for CTV, deals, reporting signals, and other media requirements.
For teams asking what is OpenRTB, the specification is not the auction itself. It is the transaction language that lets the auction happen.
Our tech staff and AdOps are formed by the best AdTech and MarTech industry specialists with 10+ years of proven track record!
FAQs
What Is OpenRTB and Who Created It?
OpenRTB is a real-time bidding standard defined by IAB Tech Lab and it is an open standard. It began as an industry project begun in 2010 by early DSP and SSP participants.
What Is the Difference Between a Bid Request and a Bid Response?
A bid request is an advertisement opportunity. The bid response will tell the seller what a DSP is willing to pay, and what creative they want to serve.
What Is the at Field in an OpenRTB Bid Request?
The at field indicates the auction type. In OpenRTB 2.6, 1 means first-price auction and 2 means second-price auction.
What Is the Difference Between OpenRTB 2.5 and OpenRTB 3.0?
This spec was in 2.5, which is the version that’s more commonly encountered in 2. x family. OpenRTB 3.0 updated the transaction model and introduced compatibility with AdCOM, but the IAB Tech Lab says OpenRTB 3.0 simply never garnered the traction across the industry.
How Does OpenRTB Support Private Marketplace Deals?
In the protocol, these are the PMP and Deal objects that hold information such as Deal IDs, to a floor price, rules about an auction and various bits of information about buyers contained within a bid request.
Is OpenRTB the Same as Header Bidding?
No. Header bidding is an auction setup used by publishers. OpenRTB is a communication specification that can carry requests and responses between systems used within programmatic auction paths.
This Article's Ad Tech terms
