> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thrads.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Pre-Rendering vs Render Endpoint

> Two ways to deliver creatives: ship the creative inline with your bid (pre-rendered) or generate it on demand when you win (render endpoint).

Your DSP has two ways to deliver the ad creative for a bid. Pick the one that matches how your creative pipeline works.

## The two paths

### Path A: Pre-rendered (default, recommended)

Include the creative directly in your bid response under `ad_data`. The SSP serves it as-is when you win and **never calls your render endpoint** for that bid.

```json theme={null}
{
  "data": {
    "bid": 7.50,
    "bidId": "bid_abc123",
    "ad_data": {
      "headline": "Premium Running Shoes",
      "description": "Perfect for marathon training.",
      "url": "https://your-dsp.com/click/abc123",
      "advertiser": "Nike",
      "domain": "nike.com",
      "image_url": "https://cdn.nike.com/ad.png"
    }
  }
}
```

**One round-trip per auction.** Lower latency, simpler operations, and the SSP doesn't need to reach back out to you.

### Path B: Render endpoint

Return only `bid` + `bidId` in the bid response. If you win the auction, the SSP calls your `/render-ad` endpoint with the `bidId` and clearing price; you respond with the creative there.

```json theme={null}
// Bid response — no ad_data
{ "data": { "bid": 7.50, "bidId": "bid_abc123" } }

// Later, if you win, SSP POSTs to your /render-ad
{ "bidId": "bid_abc123", "realizedPrice": 7.50 }
```

**Two round-trips, but only on wins.** Useful when creative generation is expensive (e.g. LLM-written copy, dynamic image composition) and you don't want to do that work for every bid — only for the ones you win.

## When to use which

| Situation                                                                | Recommended path                                                      |
| ------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| You have static, pre-built creatives in a catalog                        | **Pre-rendered** — fastest path, no reason to defer.                  |
| Your creative is templated and cheap to produce per-bid                  | **Pre-rendered** — render cost is negligible vs the extra round-trip. |
| Your creative requires a per-impression LLM call or expensive generation | **Render endpoint** — defer the work until you've won.                |
| You need to know the clearing price before finalising the creative       | **Render endpoint** — `realizedPrice` is only available on render.    |
| You're under tight latency budget and your creative is ready             | **Pre-rendered** — saves one HTTP hop on every win.                   |

## Strict validation applies to both paths

Whichever path you choose, the SSP validates the creative against the same schema:

* `ad_data` in the bid response (Path A)
* `data` in the render response (Path B)

Both use strict validation (`extra="forbid"`) and reject unknown fields. A failed validation drops the bid — no second chance, even if your bid was the highest. See the [API Reference](/dsp/api-reference/dsp-bid) for the exact field schemas.

## Mixing paths

You can choose per-bid. Some bids can include `ad_data`, others can omit it and rely on `/render-ad`. The SSP decides per response: if `ad_data` is present and valid, render is skipped; otherwise it calls `/render-ad`.

This means you can:

* Default to pre-rendering for cheap creatives.
* Fall back to the render endpoint only for bids that need just-in-time generation.

You don't have to pick one path globally.