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

# Integration Matrix

> Which demand classes are eligible on which surface, and why. Read this before you build.

Your integration path determines your rendering context, and your rendering context determines which demand you can legally and measurably serve. This is not an Adgentek policy preference. It is how the advertising measurement ecosystem works: impression-priced demand requires verification that a real user in a real client saw the ad, and that verification can only happen client-side.

Get this right at integration time and every dollar you serve is valid, measurable, and payable.

## The matrix

| Surface                   | Rendering context                | Direct (CPM)               | Programmatic (CPM)         | CPC                           | API / CPA | Impression tracking                            |
| ------------------------- | -------------------------------- | -------------------------- | -------------------------- | ----------------------------- | --------- | ---------------------------------------------- |
| Web SDK                   | Real browser                     | Eligible                   | Eligible                   | Eligible                      | Eligible  | Automatic, client-side                         |
| React SDK                 | Real browser                     | Eligible                   | Eligible                   | Eligible                      | Eligible  | Automatic, client-side                         |
| Android SDK               | Native app                       | Eligible                   | Eligible                   | Eligible                      | Eligible  | Automatic, client-side                         |
| iOS SDK                   | Native app                       | Eligible                   | Eligible                   | Eligible                      | Eligible  | Automatic, client-side                         |
| REST API, client-rendered | Your client renders the response | Eligible with pixel render | Eligible with pixel render | Eligible with click filtering | Eligible  | You must render the returned pixel client-side |
| REST API, headless        | No client render                 | Not eligible               | Not eligible               | Filtered                      | Eligible  | burl only                                      |
| AdsMCP                    | Agent surface, no browser        | Not eligible               | Not eligible               | Filtered                      | Eligible  | burl only                                      |

## What each row means

### SDK surfaces: full stack

The SDKs render the ad unit and fire the impression pixel from the user's actual device at the moment of display. Verification vendors (IAS, DoubleVerify, MOAT) see a legitimate client context. All four demand tiers compete for your inventory, which maximizes yield. If you have a user interface, use an SDK. This is the default recommendation for every publisher.

### REST API with client rendering: full stack, your responsibility

If you call the API server-side but render the response in a user-facing client, you can access the full demand stack, provided you render the impression pixel exactly as returned, in the client. The serve response includes an `imp_pixel` URL. Your client must load it as an image element when the ad is displayed:

```javascript theme={null}
new Image().src = ad.imp_pixel;
```

<Warning>
  Two failure modes will invalidate your impressions and they account for nearly all publisher tracking errors:

  1. **Firing the pixel with `fetch()` or XHR.** Cross-origin request handling means the tracking call fails silently or is stripped. Use `new Image().src`. Nothing else.
  2. **Firing the pixel from your server.** Requests from datacenter IP ranges are classified as invalid traffic (GIVT) by every major verification vendor. Those impressions will not be paid, and repeated server-side firing risks your account standing.
</Warning>

### Headless API and AdsMCP: outcome-priced demand only

Agent surfaces and headless integrations have no client that can render a pixel, so there is no valid way to verify an impression. These surfaces are therefore restricted to demand priced on outcomes:

* **CPA demand** is fully eligible. Conversions are verified at the advertiser's endpoint, so no impression verification is needed.
* **CPC demand** is eligible with mandatory click-quality filtering at the Adgentek redirect layer. Clicks that fail quality checks are discarded before billing.
* **Impression-priced demand (Direct and Programmatic CPM)** is not eligible. No exceptions, including for testing.

Billing notices on these surfaces use `burl`, the OpenRTB billing URL, fired server-to-server on receipt. `burl` confirms a billable event between Adgentek and the demand source. It is not an impression pixel and does not substitute for one.

## Choosing a path

<CardGroup cols={2}>
  <Card title="You have a UI" href="/sdk/overview">
    Use an SDK. Full demand stack, automatic tracking, nothing to get wrong.
  </Card>

  <Card title="You are an agent or headless service" href="/adsmcp/overview">
    Use AdsMCP or the API with CPA demand. Real revenue, correctly measured, no invalid traffic risk.
  </Card>
</CardGroup>

If your architecture does not map cleanly to a row above, contact [hello@adgentek.ai](mailto:hello@adgentek.ai) before building. A ten-minute integration review is faster than remediating invalid traffic.