Privacy

The API docs treat privacy as a runtime boundary, not a footnote. The public surface is designed so browser and server integrations can use minimized delivery signals instead of leaking raw model inputs to the configured ad path.

POST /v1/placements

Send a privacy-bounded placement request

Send a topic object when you need matching context, and keep prompt_shared false when raw prompt text must not enter the targeting path.

Create a privacy-bounded placement

privacy.sh

bash

cURL
curl -X POST https://api.wavebird.ai/v1/placements \  -H "Authorization: Bearer $WAVEBIRD_SECRET_KEY" \  -H "Content-Type: application/json" \  -d '{    "client_id": "wbproj_...",    "session_id": "sess_...",    "job_type": "chat",    "prompt": { "topic": "programming" },    "consent": {      "semantic_targeting": true,      "prompt_shared": false,      "gdpr_applies": true,      "consent_source": "wavebird_consent"    }  }'

Recommended

Default privacy posture

Minimal signal egress

The default path sends only a narrowed delivery signal such as topic category and language, not raw prompt text.

Consent-bounded relevance

Semantic relevance must remain bounded by the active consent profile and the current jurisdiction mode.

No model influence

The ad path remains separate from model I/O. Sponsored delivery does not rewrite prompts or influence outputs.

API-first reading

What the docs now assume

Browser teams should read privacy in terms of activation, consent storage, and render-time config. Backend teams should read privacy in terms of the request fields they choose to send into placement creation. The advanced SDK does not change those boundaries.

Need rollout review?

Start with the Server API. Use contact only when you need rollout review, enterprise coordination, or non-standard integration help.

Contact the team