Skip to main content
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

SurfaceRendering contextDirect (CPM)Programmatic (CPM)CPCAPI / CPAImpression tracking
Web SDKReal browserEligibleEligibleEligibleEligibleAutomatic, client-side
React SDKReal browserEligibleEligibleEligibleEligibleAutomatic, client-side
Android SDKNative appEligibleEligibleEligibleEligibleAutomatic, client-side
iOS SDKNative appEligibleEligibleEligibleEligibleAutomatic, client-side
REST API, client-renderedYour client renders the responseEligible with pixel renderEligible with pixel renderEligible with click filteringEligibleYou must render the returned pixel client-side
REST API, headlessNo client renderNot eligibleNot eligibleFilteredEligibleburl only
AdsMCPAgent surface, no browserNot eligibleNot eligibleFilteredEligibleburl 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: 
new Image().src = ad.imp_pixel;
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.

​
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

You have a UI

Use an SDK. Full demand stack, automatic tracking, nothing to get wrong.

You are an agent or headless service

Use AdsMCP or the API with CPA demand. Real revenue, correctly measured, no invalid traffic risk.
If your architecture does not map cleanly to a row above, contact hello@adgentek.ai before building. A ten-minute integration review is faster than remediating invalid traffic.