Are unknown or extra fields in a bid request a problem?
Answer
Usually tolerated, occasionally fatal, always worth knowing about. The spec's extension convention is that custom data belongs inside ext objects; fields invented at other paths are undefined behavior. Lenient parsers skip them, strict ones reject the request, and either way you are shipping bytes that no partner reads. Unknown fields are also the fingerprint of drift: a typo (bidflor), a field at its pre-2.6 path, or a partner-specific field leaking into traffic for everyone. RTBlint flags every field not in the catalog for the version you target, with the exact path.
Go deeper
More questions on debugging, no-bids, and validation
- Why is my bidder not receiving bid requests? Work the path from the exchange inward: confirm the endpoint the exchange has on file matches what you deployed (scheme, host, path), that your endpoint returns a well-formed response or HTTP 204 quickly enough to stay under the exchange's timeout, and that traffic filters on the exchange side (geo, media type, QPS caps, pretargeting) are not excluding you.
- Why is my bid rate low even though I receive requests? Start by separating deliberate no-bids from failures.
- How do I find out why my bids are losing auctions? Ask for loss reasons via the loss notice URL.
- How do I debug a systematic OpenRTB no-bid? If the bidder returns a BidResponse with nbr set, the code tells you where to look: nbr 2 is Invalid Request, which means the bidder could not parse or accept your bid request, so run the request through a validator before anything else.
- What does HTTP 204 mean in OpenRTB, and how is it different from nbr? HTTP 204 No Content is the spec's preferred way for a bidder to say it has no bid: no body, cheapest possible round trip.
- How do I validate an OpenRTB bid request? Paste it into a validator that checks against the actual spec catalog, not just JSON syntax.
All 93 questions are listed in the OpenRTB FAQ.