# OpenRTB 3.0: the IAB specification for real time bidding

> The InteractiveAdvertisingBureau/openrtb repository holds the OpenRTB 3.0 specification, the wire contract that let exchanges and demand side platforms bid on the same impression in milliseconds. It is a document repository rather than code, and its value to an engineer is knowing exactly which version of the contract your counterpart implemented.

**InteractiveAdvertisingBureau/openrtb** — Open RTB is a protocol for real time bidding on digital media

- Repository: https://github.com/InteractiveAdvertisingBureau/openrtb
- Website: https://iabtechlab.com/openrtb
- Stars: 527 · Forks: 218
- Language: Unknown
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/interactiveadvertisingbureau-openrtb

## A repository of documents where engineers usually expect a library

The first thing to understand about this repository is what it is not. There is no client library, no server, no test harness and no build system. The top level holds a gitignore, the README, the specification document itself named OpenRTB v3.0 FINAL.md, a document on the supply chain object, an extensions directory, and a separate file for signed bid requests. OpenRTB is the protocol for real time bidding on digital media, and the repository is where that protocol is written down and versioned. The organisation behind it, the IAB Technology Laboratory, describes itself as a nonprofit research and development consortium charged with producing and helping companies implement global industry technical standards, so a document repository is the expected shape of the output. For an engineer, the practical value is narrower than a library would be and quite different: it tells you what bytes go on the wire.

## master holds the release, develop holds the churn, branches hold history

The branching scheme is the release management story of the whole repository, and it is documented at the top of the README. At all times the master branch contains the most recent release of OpenRTB, and the specification file in that branch is the one to read for the latest version. Branches exist for prior releases, and the documentation is explicit about their purpose: to review detailed changes from one release to another. That means the diff between two branches is a readable record of what changed between two versions of the contract, which is far more useful than a changelog line when you are chasing a field that your ad server suddenly started rejecting. A brief change log is found inside the spec itself, so the document and its history live together. One naming detail is worth flagging: the README describes master as the release branch, while the repository default branch is listed as main, so check which branch actually holds the current release before you pin a reference in your own documentation.

## The develop branch is where nothing is settled

Alongside the release branches there is a develop branch, and the README is blunt about its status: it contains work in progress for an upcoming release and may change at any time. That single sentence is the most important operating rule in the repository. If you read a field definition from develop and build a parser against it, you have built against a document with no stability guarantee, and you have no way to tell from the field name alone whether it will survive into the next release. The same caution applies to the extensions directory, whose contents the visible documentation does not describe. For a team integrating against OpenRTB, the safe practice is to point at a specific release branch, record which one, and treat develop as a place to watch for upcoming changes rather than as a specification to implement.

## The spec sits alongside AdCOM, OpenMedia and the supply chain object

The README links three related bodies of work, and the differences between them are what a newcomer has to sort out. The AdCOM reference points to a separate repository for the Advertising Common Object Model, a different specification living in a different project, so the object definitions OpenRTB refers to are not contained in this repository. The OpenMedia link points to another IAB programme at the tech lab, a separate set of standards rather than part of the bidding protocol. The supply chain object, by contrast, is a document inside this repository, sitting next to the main specification, and it is the piece that describes how the advertising supply chain itself is modelled. Separately, there is a file for signed bid requests at version 1.0 BETA, which is a different approach to the trust problem in the auction: rather than relying on the transport and the shared keys alone, the request is signed. Read the supply chain object and the signed request document alongside the main spec rather than after it, because they change how you interpret the request fields.

## The alternative to implementing OpenRTB is implementing a subset

There is a practical alternative to the full specification, and it is the approach most teams actually take: implement only the subset of the request and response that your counterpart sends, and ignore the rest. The difference in approach is real. Full implementation means handling every object and field the standard defines, which buys you the ability to accept any conforming counterpart without code changes. Subset implementation means fewer fields to parse and fewer edge cases to test, but it hard-codes an assumption about the other side that you will discover is wrong at the worst possible moment, in production, during a bid. The other alternative is a proprietary wire format agreed bilaterally, which avoids the standards work entirely at the cost of a new integration for every partner. OpenRTB exists precisely to remove that last cost, and the branch structure exists so that a team on version 3.0 can read exactly what changed when a partner moves to the next release.

## Change control is a working group process, not a pull request

Who can change the specification is a governance question with a clear answer in the README. Contributions come from OpenRTB Working Group members, and participants in the Programmatic Supply Working group must be members of the IAB Tech Lab. Technical governance and the code commits for the project are provided by the IAB Tech Lab Programmatic Supply Chain Commit Group. The process for proposing a change is documented on the tech lab blog under the title So, You Would Like to Propose a Change. This matters practically if you maintain a parser: you cannot simply open a pull request against a field you need, and you cannot expect an upstream fix on your schedule. If your integration breaks because of a spec change, your options are to follow the new release on the branch, adapt on your side, or route the request through the working group, which is a slow path for a production outage.

## CC-BY 3.0 covers the specification, and compliance stays with you

The licence arrangement is straightforward and worth reading closely, because there are two parts. The OpenRTB specification is licensed by the IAB Tech Lab under a Creative Commons Attribution 3.0 License. Separately, the submission terms state that by submitting an idea, specification, code, document or file to the OpenRTB repository, to a member of the Programmatic Supply Chain Working Group, or to the tech lab in relation to OpenRTB 3.0, you agree to license that submission under the same Creative Commons Attribution 3.0 terms and that it may be made available to the public. If you are a member of the tech lab, the IPR Policy acknowledgement may also apply, and in a conflict the IPR Policy controls. Practically, the practical consequence is attribution: cite the spec and version. The disclaimer is where the risk sits, because it explicitly places legal and regulatory compliance on the implementer, naming data protection regimes including the GDPR and the ePrivacy rules among others.

## Maintenance state and what the release history actually shows

The repository is not archived, and the last push was on 2026-10-09, so the documents are being touched. There are no GitHub releases, which is expected for a specification repository that distributes versions through branches rather than through packaged artefacts. That means there is no changelog page to read on the releases tab and no version number to pin; the branch you checkout is the version. For an engineer, that is the practical difference from every other dependency in a stack, and it argues for recording the branch and the date in your own integration documentation rather than assuming a semver range will work. The home page for the specification is at iabtechlab.com/openrtb, the tech lab publishes a general page describing the consortium, and questions about the standard or participation in the working group go to support@iabtechlab.com.

## Conclusion

Adopt the openrtb repository as the reference your team implements against when you build or review an OpenRTB bidder, exchange adapter or supply side integration, and pin the specific release branch your counterpart uses. Do not treat it as a library, a validator or a test suite, because it contains a specification and supporting documents and nothing that runs against your traffic. Before you start, read the OpenRTB v3.0 FINAL document for the request and response objects, check the extensions directory for the features you need, and confirm with your partner which release they implement, since the repository keeps the current release on master and prior releases on separate branches.

## FAQ

### Where do I find the latest OpenRTB specification?

The master branch holds the most recent release, and the specification file in that branch is the one to read, named OpenRTB v3.0 FINAL.md. Branches exist for prior releases so you can review detailed changes between versions, and a brief change log is included in the spec itself.

### Should I implement against the develop branch of OpenRTB?

The documentation states that the develop branch contains work in progress for an upcoming release and may change at any time. Read it to watch for upcoming changes, but point an implementation at a specific release branch, since the work in progress carries no stability guarantee.

### What licence applies to the OpenRTB specification?

The OpenRTB specification is licensed by the IAB Tech Lab under a Creative Commons Attribution 3.0 License, and submissions to the repository are licensed to the tech lab on the same terms. Members of the tech lab are also subject to the IPR Policy, which controls in the event of a conflict.

### How do I propose a change to OpenRTB?

Contributions come from OpenRTB Working Group members, and participants in the Programmatic Supply Working group must be members of the IAB Tech Lab. Technical governance and commits are handled by the Programmatic Supply Chain Commit Group, and the process is described in the tech lab blog post on proposing a change.

## Sources

- [InteractiveAdvertisingBureau/openrtb on GitHub](https://github.com/InteractiveAdvertisingBureau/openrtb)
- [Issues](https://github.com/InteractiveAdvertisingBureau/openrtb/issues)
- [Project website](https://iabtechlab.com/openrtb)
- [README](https://github.com/InteractiveAdvertisingBureau/openrtb/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/interactiveadvertisingbureau-openrtb