OpenRTB Is Not Just JSON

OpenRTB looks, at first glance, like one of the easiest integration problems in software. It's an open, documented standard. A bid request is a JSON object with well-defined fields; a bid response is another. Read the spec, implement the schema, and surely you can talk to any exchange that speaks it. Engineers new to adtech often assume integration is a weekend of JSON wrangling.

Then they connect to actual exchanges, and reality arrives. The spec is the easy 10%. The hard 90% is everything the spec can't make uniform: every exchange interprets the standard slightly differently, extends it with proprietary fields, populates it inconsistently, and — often enough — sends things that don't conform at all. OpenRTB is not just JSON. It's a negotiated agreement that each party honors differently, and making sense of that at scale is the actual engineering.

A standard is an agreement, not a guarantee

The promise of a standard is interoperability: implement it once, connect to everyone. The reality is that a standard defines a common language, not a common dialect. OpenRTB tells exchanges and bidders how to structure a conversation, but it cannot force them to:

• populate the same fields with the same fidelity,
• interpret optional fields the same way,
• avoid proprietary extensions for their own features, or
• always send well-formed requests under load.

So a bidder built strictly to the spec, expecting every exchange to match it, breaks on contact with the real ecosystem. The spec is necessary and insufficient — the floor of integration, not the ceiling.

Where exchanges actually diverge

The heterogeneity shows up in specific, predictable places:

• Proprietary protocols. Some major exchanges don't even speak OpenRTB natively. Google's Realtime Bidding protocol is its own format; talking to it means translating its protocol into your internal model, not just parsing JSON.
• Field availability. As the data spec itself states, fields available in the upstream bid request are exposed where present and supported by the supply source — availability varies by exchange, inventory type, and integration. A field that's reliably present on one exchange is routinely absent on another.
• Extensions and quirks. Exchanges add ext fields and custom semantics for their own capabilities; handling them means per-exchange knowledge layered on the shared standard.
• Malformed and edge-case requests. At billions of requests, you will receive things that don't conform. A robust bidder has to handle the malformed gracefully rather than assuming the spec is always honored.

None of this is in the spec, and all of it is the job.

The honest answer: normalize, then specialize

The way out is not to fight the heterogeneity request-by-request, but to normalize it. The pattern is to build the bidder on OpenRTB protocol buffers behind a unified internal interface — Ad360's Ad360BidRequest / Ad360BidResponse — and to write converters that translate each exchange's actual protocol (including proprietary ones like Google's) into that single internal model. The core decisioning logic then sees one consistent shape, no matter how many exchange dialects feed it.

This is the architectural payoff that makes integration tractable, and it's the subject of its own deeper discussion (the exchange abstraction layer). The point here is why it's necessary: without normalization, every exchange's quirks leak into core logic and the system forks itself into unmaintainability.

The effort is administrative, not just technical

There's a counterintuitive truth that experienced integrators know: once the abstraction exists, the bottleneck to adding an exchange is often not engineering. As Ad360's own integration notes put it, the whole point of implementing an industry-wide protocol the way they did is to streamline integration — so "the effort is more on the administrative side: getting vetted, negotiating minimum spend, and financial terms." The technical normalization is built once; each new exchange is then more of a business onboarding (vetting, commercials) than a from-scratch engineering project.

That's a sign of a healthy architecture: the standard plus a converter layer turns what looks like N integration projects into one integration framework plus N administrative onboardings. It does not mean integration is trivial — it means the hard technical work was front-loaded into the abstraction.

Common misconceptions

• "OpenRTB integration is just parsing JSON." The spec is the easy part; heterogeneity, extensions, and malformed traffic are the work.
• "A standard guarantees interoperability." It defines a language, not a uniform dialect; each exchange honors it differently.
• "Every exchange speaks OpenRTB." Some use proprietary protocols that must be converted into your internal model.
• "If a field is in the spec, it'll be there." Field availability varies by exchange, inventory, and integration.
• "More exchanges means proportionally more engineering." With normalization, added exchanges are largely administrative onboarding.

What good operation looks like

• Build to an internal model, not to any single exchange's wire format.
• Write converters per exchange/protocol; keep core logic dialect-free.
• Expect and handle non-conformance (missing fields, malformed requests) gracefully.
• Track field availability per source rather than assuming spec completeness.
• Recognize that, post-abstraction, onboarding is mostly administrative — plan for vetting and commercials.

Open questions

• How should bidders signal and document per-exchange field availability to downstream consumers?
• As OpenRTB evolves (2.6, DOOH/audio/CTV extensions), how do you absorb new extensions without forking?
• What's the right conformance-testing discipline for onboarding a new, quirk-laden exchange?

OpenRTB being "open" and "standardized" creates a comfortable illusion that integration is a solved, trivial problem. The spec is genuinely the easy part. The real work is taming an ecosystem where every exchange speaks the standard with its own accent, extends it for its own needs, and occasionally mangles it under load. Treat OpenRTB as just JSON and you'll drown in special cases. Treat it as a language to be normalized behind one internal model, and integration becomes something you do once well — and then mostly negotiate.