OpenRTB is an open protocol for exchanging bid requests and bid responses between advertising systems. The protocol defines the message contract; a production platform still needs routing, validation, capacity controls, reporting and commercial policy.

01

The request lifecycle

A publisher or SSP creates a bid request describing an impression opportunity. An exchange or routing layer validates it, selects eligible demand endpoints and waits within a bounded auction window. DSPs return bids, the auction chooses an eligible result and the delivery path records notices and outcomes.

  • Supply request validation
  • Demand endpoint selection
  • Auction timeout boundary
  • Bid and win visibility
02

What the protocol does not solve

OpenRTB does not decide which commercial relationships are valid, how much QPS a partner may send, which filters protect inventory or how operators investigate loss reasons. Those responsibilities belong to the platform operating around the bidstream.

03

How Nexus approaches OpenRTB

Nexus places tenant configuration, demand routes, QPS governance, endpoint mappings and operational visibility around the auction service. The objective is a bidstream commercial and technical teams can reason about together.

Product accuracy

This guide describes Nexus product architecture and general AdTech operating concepts. Exact enforcement and integration behavior depends on the enabled revenue engine and agreed deployment configuration.