OpenRTB Overview

How CloudX calls your OpenRTB endpoint: protocol versions, transport, auction semantics, timeouts, currency, and blocked IAB categories.

CloudX may call your server in each executed auction round where your endpoint is eligible. A single impression opportunity can therefore produce multiple requests to the same endpoint when earlier rounds do not fill. Your endpoint returns a bid response; the winning creative is rendered by the CloudX SDK. This page covers the protocol-level contract. The field-level guides are Bid Requests and Bid Responses.

Protocol

• Versions: OpenRTB 2.5 or 2.6, configured per endpoint during onboarding. Version differences that matter to you — source.schain vs source.ext.schain, user.eids vs user.ext.eids — are called out in the field guides.
• Transport: HTTPS POST with a JSON body (Content-Type: application/json). Keep connections alive; CloudX may send a separate request for each eligible round that executes.
• Compression: CloudX can compress request bodies per endpoint. You may compress a response only with an encoding advertised by that individual request’s Accept-Encoding header; otherwise send it uncompressed. The default advertisement is gzip, zstd, but endpoint configuration can differ, so inspect every request. See Bid Traffic Compression.
• One impression per request: each bid request carries exactly one imp object. Bid on it or pass — there is no multi-impression batching.

Auction semantics

CloudX runs a first-price auction: if your bid wins, you pay the CPM you bid. Auctions run in rounds defined by the publisher’s line items. CloudX applies any applicable bid adjustments and the round’s price floor before ranking; the highest adjusted bid in the first round with a valid bid wins. Ties are broken at random.

For supported integrations, a round can rank bids inside a Trusted Execution Environment and produce verifiable evidence. Standard integrations keep the request and response contract described here; CloudX provides optional TEE details during onboarding.

Timeout

Every bid request carries tmax, the number of milliseconds you have to respond, measured from when CloudX sends the request. CloudX sets tmax per endpoint (1400 ms by default). Responses that arrive after the deadline are discarded and do not participate in the auction.

No-bid

To pass on an impression, return either:

• HTTP 204 with an empty body, or
• HTTP 200 with an empty seatbid array. Use this form when you want to report a reason in nbr (OpenRTB List 5.24) — a 204 cannot carry a body.

Currency

All prices are US dollars. bidfloor on the request and price on the response are USD CPMs.

Blocked categories

The following IAB Content Taxonomy 1.0 codes are on CloudX’s network policy block list:

In OpenRTB 2.6, request cattax identifies the taxonomy for bcat: 1 means IAB Content Taxonomy 1.0, and omission defaults to 1. For these categories, set bid cattax to 1 or omit it; the same default applies to bid.cat.

Publishers can add category exclusions. Always honor the complete bcat array in each bid request, and accurately categorize the creative and landing page in bid.cat. Do not bid with a category listed in bcat.

Category matching uses exact codes; a parent code does not automatically match its subcategories. For example, IAB8 does not match IAB8-5. Return accurate category codes; do not use a broader parent code to avoid a block.

Publishers can also configure advertiser-domain exclusions in badv and advertised-app exclusions in bapp. Honor both arrays in each request. bapp identifies apps by Android package name or numeric iOS App Store ID; return the advertised app’s identifier in bid.bundle when the ad promotes an app.

Category exclusions use loss reason 209, and advertiser-domain exclusions use 6. App exclusions use 215, creative-attribute exclusions use 210, and creative or campaign ID exclusions use 200. See Loss reason codes for the notification meanings.

Restricted content, including gambling, alcohol, and financial products or services, still requires CloudX permission and regulatory compliance under the Demand Partner Policy. Permission does not override a category block in the request. See Restricted content.

What’s next