Flag field is true/false where OpenRTB wants 0 or 1
A flag field arrived as a boolean. The specification types it as an integer, but the IAB OpenRTB protobuf schema declares it bool, so this is a protobuf JSON payload sent to a spec JSON reader.
What it means
A field such as imp.secure, regs.coppa or pmp.private_auction arrived as true or false. The OpenRTB specification types 28 such flag fields as integers with the value set {0, 1}. The IAB OpenRTB protobuf schema declares those same fields bool, so a payload produced by protojson writes booleans and a payload produced from the specification writes integers.
Why it matters
Neither encoding is wrong on its own transport, which is what makes this expensive to find. A gRPC integration serialising with protojson produces booleans that a JSON exchange's typed parser rejects, and the rejection looks like a schema bug rather than a transport mismatch. The bare type error, 'expects integer but received boolean', sends people to check their builder when their builder is correct and their assumption about the reader is not.
How to fix it
If the payload is going to a JSON exchange, send the integer form: 1 for true, 0 for false. If it is a protobuf JSON payload you are validating deliberately, say so, with --dialect proto-json on the CLI, dialect: "proto-json" on the MCP tools, or JSON_DIALECT_PROTO in the gRPC ValidationContext.
Example that trips it
{ "id": "req-1", "imp": [{ "id": "1", "secure": true, "banner": { "w": 300, "h": 250 } }] }Correct as protobuf JSON, invalid as OpenRTB JSON. The payload carries no marker saying which one it is, so the validator is told rather than left to guess.
Check your payload
Paste a bid request or response into the tester to see whether this code fires against it, or gate on the id in CI with the CLI: the id is stable, wording is not.
Back to the full diagnostic code reference.