OpenRTB protocol
tmax in OpenRTB: auction timeouts explained
tmax is an integer on the top-level BidRequest object. The OpenRTB 2.6 spec defines it as the "maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout. This value supersedes any a priori guidance from the exchange." Miss it and your bid never enters the auction.
What the definition actually implies
Two details in that one sentence do all the work. First, the clock includes Internet latency: tmax is measured at the exchange, from when it sends the request to when your response arrives back. Your compute budget is tmax minus the full network round trip. With "tmax": 120 and 40 ms of round trip to the exchange, you have roughly 80 ms to parse, price, and respond, less once you leave headroom for jitter.
Second, it supersedes a priori guidance. Exchanges publish default timeouts at integration time, but a tmax in the request overrides them per auction. Header bidding wrappers often shrink it because the exchange itself sits inside someone else's timeout.
Typical values in production run 100 to 300 ms. Server-to-server paths and CTV tend toward the higher end; requests relayed through several intermediaries carry tighter budgets at each hop.
Timeout vs 204 vs nbr
A bidder that misses tmax is silently dropped: the exchange closed the auction, the late bid is discarded, and exchange reporting counts it as a timeout. That is a different event from a deliberate no-bid, which is either an empty HTTP 204 response or a BidResponse carrying a no-bid reason code in nbr. The full code table is in OpenRTB no-bid reason codes. If you are debugging a bidder whose bid rate dropped, ask the exchange for its timeout rate first: a timeout looks like a no-bid in win-rate dashboards but has a different fix.
Fields that look related but are not
imp.exp and bid.exp both deal in seconds, not milliseconds, and describe expiration, not timeouts. imp.exp is advisory: the number of seconds that may elapse between the auction and the actual impression. bid.exp is the bidder's side of the same handshake: how many seconds it is willing to wait between auction and impression. They matter for mediated and SSAI inventory where the render can lag the auction by minutes, and have nothing to do with tmax. There is no timeout field on source; if you see one there, it is exchange-specific.
OpenRTB 3.0 keeps tmax on its Request object with the same millisecond, latency-inclusive definition, and adds explicit guidance that an intermediary should decrease the outbound tmax to account for its own latency and the extra hop.
FAQ
Is tmax required in OpenRTB?
No. tmax is an optional integer on the BidRequest object, set by the exchange. When present it supersedes any a priori guidance the exchange has published. When absent, the integration-time timeout agreement applies.
Does tmax include network time?
Yes. The spec defines tmax as the maximum time in milliseconds the exchange allows for bids to be received, including Internet latency. The clock covers the full round trip, not just bidder compute time, so a bidder must respond in less than tmax minus the network round trip to the exchange.
What happens if a bidder exceeds tmax?
The exchange has already closed the auction, so the late response is discarded and typically counted as a timeout in exchange reporting. No nbr code is involved; nbr is something the bidder sends, and a timed-out bidder by definition sent nothing in time.
Validate it
A tmax sent as the string "120" instead of the integer 120 is a real and common integration bug. Paste a request into the bid request tester and rtblint checks types against the spec, alongside every other field in the bid request. The CLI runs the same rules in CI.