Integration flow
The public API flow is intentionally small. Browser paths add activation. Server paths do not. Everything else reduces to jobs, decisions, rendering, and beacons.
1. Load project context
Resolve client_id and the right key class for the surface: publishable key for the browser path, secret key for the backend path.
2. Activate the browser when needed
Script Tag or advanced browser integrations exchange the publishable key for an origin-bound activation token before runtime calls.
3. Create a job
Create the monetization unit for the current interaction. Jobs can stay minimal or carry prompt hints, slot hints, and overrides.
4. Read the decision
Fetch the slot decision from the canonical /v1 surface. The result is either a fill with structured creative payload or a no-fill with a stable reason code.
5. Render and disclose
Render the slot in your chosen surface, keep sponsor disclosure visible, and apply your configured brand-safety and consent boundaries.
6. Send beacons
Record rendered, visibility, click, or clip-completion events so diagnostics and billing evidence stay complete.
Script Tag path
Handles activation, config loading, slot discovery, consent prompting, rendering, and beacon wiring for you.
Server API path
Keeps orchestration on your backend. You explicitly call jobs, decisions, and beacons and can pair that with your own renderer or frontend framework.
Need rollout review?
Start in the dashboard, choose Script Tag or Server API, and use contact only when you need rollout review, enterprise coordination, or non-standard integration help. Billing beacon rules live in the API concepts guide.