Server API
Server API is the recommended default backend path. Use it when your backend already owns session state, orchestration, or rollout policy, while wavebird owns hosted media rendering in the browser.
.env.local
bash
create-placement.sh
bash
app/api/sponsor-slot/route.ts
typescript
chat.html
html
Credentials
Server Test Key
Start with a Server Test Key from Dashboard API Keys. The full sk_test_... value is shown only when the key is created or rotated, so copy it immediately into WAVEBIRD_SECRET_KEY. If the dashboard only shows a masked preview, create or rotate a Server Test Key before running the Server API examples. Test requests are non-billable.
REST placement
Controlled request fields
Send controlled format, size, position, and consent values to your same-origin sponsor-slot endpoint. That server route validates the body and forwards only supported fields to wavebird. Never put API keys, raw prompts, chat text, identities, or other secrets in the browser request. The renderer does not read adata-wavebird-request attribute.
Required fields
What the first Test request needs
Project and session
client_id selects the wavebird project and must match the Server Test Key. session_id is a stable anonymous identifier for one test conversation. Do not use an email address, account ID, prompt, or other personal identifier.
Request type
job_type describes the product surface, such as chat, code, image, voice, or agent. It does not contain the user's message. slots_requested defaults to one.
Consent is not optional for this Test setup
Dashboard-created Test projects use an authoritative consent lifecycle. Include the request-level consent object shown above or sync a current record first. Omitting both can return 403 consent_not_current.
Synthetic Test boundary
The example uses gdpr_applies: false only for synthetic Test sessions that do not represent real users. For real-user traffic, derive jurisdiction and consent from the actual request and complete the required legal setup first.
Request controls
Consent fields
The example disables semantic targeting and raw prompt sharing. Derive gdpr_applies from the actual request and use the appropriate consent_source. Request-level consent can be included in the placement request; use /v1/consent to synchronize a decision separately.
Browser lifecycle
Filled, no-fill, and render status
Filled
The canonical API response has no top-level filled field. A fill has placement and normally decision.fill: true. Pass placement, optional decision, and authoritative_consent to renderPlacement.
No-fill
When placement is absent and decision.fill is false, hide or clear the slot and continue the normal app flow. Read decision.no_fill_reason for the controlled reason. No-fill is not an integration error.
Classify every successful response as filled, no_fill, not_ready, or invalid_response. Only filled may be passed to the hosted renderer.
To exercise this branch deterministically in Test, use /v1/placements?wait_ms=1500&test_outcome=no_fill with a Server Test Key. Remove the parameter for ordinary fill requests; Production keys reject it.
Render failure
Listen for the controlled ad:render_failed event or inspect data-wavebird-status="frame_error". Do not invent a successful render signal.
The hosted renderer waits for the creative medium before sending positive render and visibility signals. Treat the render as successful only when renderPlacement() returns a cleanup function. Anull result, ad:render_failed, or data-wavebird-status="frame_error" is a controlled render failure. A mounted frame alone is not proof of a completed render. withTurn()is an optional Script Tag lifecycle helper and is not required for this REST path.
Hosted renderer
Publisher Content Security Policy
Load https://api.wavebird.ai/v1/render.js directly and allow https://api.wavebird.aiin the publisher's script-src, frame-src, and connect-src directives. Do not proxy the renderer, hosted creative frame, or beacons through the publisher app.
Hosted renderer
Measurement
The hosted renderer sends browser beacons to /public/wrapper/v1/beacons. A refused, expired, or revoked lifecycle decision prevents rendering and beacons.
Direct /v1/beacons calls are for custom rendering or QA. They require the issued asset_token, a fresh occurred_at, and idempotent beacon_id values. Keep the asset token out of logs and client-visible debug output.
After testing
Production credentials
Use sk_dry_... for non-billable production dry-run. Enable live delivery and complete payout setup before using a Server Production Key. Browser Publishable Keys are only for browser activation and Script Tag flows.
Do not add production_dry_run, production_billing_dry_run, billing_suppressed, or production_live_approved to request bodies.
Advanced request controls and direct beacons
advanced-policy-controls.json
json
direct-server-beacon.mjs
javascript
Troubleshooting
Timestamp freshness
Avoid BEACON_TOO_LATE
occurred_at must be close to when the event actually happened. Copying an old static sample timestamp can return BEACON_TOO_LATE. Generate it at runtime with const occurred_at = new Date().toISOString();.
Need help with your integration?
Share the affected endpoint, request ID, and the behavior you expected. Leave out keys and user content.