> For the complete documentation index, see [llms.txt](https://docs.exoclick.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.exoclick.com/rtb/publishers/open-rtb/pub-open-rtb-2.5-response.md). # Open RTB 2.5 Bid Response The response for a bid request will have the following structure: ## Bid Response Object | Attribute | Description | | --------- | ------------------------------------------------------------------- | | id | ID of the bid request (string) | | seatbid | Collection of bids made by the bidder on behalf of a specific seat. | ### seatbid | Attribute | Description | | --------- | -------------------------------------------------------------- | | bid | ID of the impression object to which this bid applies (string) | ### seatbid.bid | Attribute | Description | | --------- | ---------------------------------------------------------------- | | id | ID for the bid object chosen by the bidder (string) | | impid | ID of the impression object to which this bid applies (string) | | price | Bid price in CPM or CPC (float) | | adm | ExoClick XML Ad Markup (string) | | nurl | Win notification URL (string) | | burl | Billing notification URL (string) | | cid | Campaign ID to assist with ad quality checking (string) | | crid | Creative ID to assist with ad quality checking (string) | | adid | Ad ID to assist with ad quality checking (same as crid) (string) | | adomain | Advertiser domain, or exchange domain (array of strings) | | cat | IAB content categories of the creative (string array) | | w | Width of creative (integer) | | h | Height of creative (integer) | | ext | ExoClick specific extension (object) | ### seatbid.bid.ext | Attribute | Description | | --------- | --------------------------------------------------------------------------------------------------------------- | | btype | Pricing Model. Values: 1 = CPM, 2 = CPC. Default = 1 (int). | | | **Note**: Only Push Notification, Native ads, Direct Link, and Email Clicks may bid with the CPC pricing model. | ## No Bid Response To answer a bid request without making an actual bid, an HTTP response code 204 "No Content" will be sent. ## Win Notification When the parameter **Bid Response Object -> Seat Bid Object -> Bid Object -> nurl** is in the bid response, a GET request must be performed to such URL. ## Billing Notification When the parameter **Bid Response Object > Seat Bid Object > Bid Object > burl** is in the bid response, a GET request is performed to that URL when the impression or click becomes billable (CPM or CPC, per the `btype` field). This allows the impression or click to be counted from the billable event rather than from Client-side-based tracking, and provides parallel **"Served" metrics** in the [RTB Statistics.](/publishers/publisher-statistics.md#the-real-time-bidding-panel) that show the gap between what was rendered and what was billed. If both nurl and burl are present, both should be called. ### Count Logic * **When BURL is disabled** — The Impression or Click rely entirely on client-side tracker fired by the rendered ad. Today's default for counting impressions and clicks. * **When BURL is enabled** — The Impression or Click is counted from the burl call instead of the client-side tracking. * **When BURL enabled but partner fails to fire** — The Impression or Click count drops to zero for billing purposes, while served impressions (what the browser logged) remain. This discrepancy flags a technical integration issue. ### What stays on Client-side tracking * **Frequency Capping**. FC continues to rely on impression events regardless of the BURL toggle. * **All "Served" metrics**, by definition. * **Direct (non-RTB) zones**, which have no BURL concept. ### Billing Notification When the parameter **Bid Response Object > Seat Bid Object > Bid Object > burl** is in the bid response, a GET request is performed to that URL when the impression or click becomes billable (CPM or CPC, per the `btype` field). This allows the impression or click to be counted from the billable event rather than from Client-side-based tracking, and provides parallel **"Served" metrics** in the [RTB Statistics.](/publishers/publisher-statistics.md#the-real-time-bidding-panel) that show the gap between what was rendered and what was billed. If both nurl and burl are present, both should be called. #### Count Logic * **When BURL is disabled** — The Impression or Click rely entirely on client-side tracker fired by the rendered ad. Today's default for counting impressions and clicks. * **When BURL is enabled** — The Impression or Click is counted from the burl call instead of the client-side tracking. * **When BURL enabled but partner fails to fire** — The Impression or Click count drops to zero for billing purposes, while served impressions (what the browser logged) remain. This discrepancy flags a technical integration issue. #### What stays on Client-side tracking * **Frequency Capping**. FC continues to rely on impression events regardless of the BURL toggle. * **All "Served" metrics**, by definition. * **Direct (non-RTB) zones**, which have no BURL concept. ## Examples You can find detailed examples of the Responses you can receive in the [example page](/rtb/publishers/open-rtb/open-rtb-2.5-pub-code-examples.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.exoclick.com/rtb/publishers/open-rtb/pub-open-rtb-2.5-response.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.