Concepts
The API surface is organized around a small set of stable runtime concepts. Read these first if you want the wire model clear before you choose Script Tag, Server API, or the advanced SDK.
The shortest mental model is: client_id loads project defaults, the browser path starts with activation, your app creates a job, every job produces one or more decisions, and rendered slots emit beacons.
client_id
The stable public identifier for a project. Browser and server integrations use it to load project defaults, non-secret config, and routing context without exposing a secret key.
Browser activation
The publishable-key exchange that binds browser traffic to allowed origins. Script Tag and advanced browser integrations use this before calling protected runtime routes.
Activation is why publishable keys stay browser-safe only when allowed origins are enforced. See API configuration.
Job
The canonical unit of work for one monetization opportunity. A job creates one or more slot IDs and brackets the decision and beacon lifecycle for that prompt or interaction.
Jobs are intentionally small. You can start with just job_type and slots_requested, then add prompt hints, slot hints, or overrides as your integration needs more control.
Decision
The latest sponsor result for a slot. A decision can be a fill or a no-fill, and it carries the structured creative payload or stable no-fill reason codes.
Beacon
A lifecycle event recorded after rendering, visibility, or clip playback. Beacons turn ad delivery into auditable evidence for billing and diagnostics.
For proof and billing context behind these events, see proof integrity.
Project config
The non-secret runtime configuration exposed to browser renderers and debug tooling. This includes format hints, disclosure labels, and consent-related defaults.
Consent and privacy
Consent is not a side topic. The public API includes explicit consent storage and routing behavior because semantic relevance and persistence must stay policy-bounded.
API before SDK
The SDK does not define the core concepts anymore. It adapts to these runtime contracts. That is why the API docs are now the canonical reference.
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.