Migration from pre-transition SDK

Existing SDK integrations keep working, but new rollouts should prefer the Server API default first.

Hosted path

Server API integrations can call POST /v1/placements?wait_ms=1500 and render with the hosted render.js flow when they do not need the SDK job-plus-decision sequence in app code.

Use /api/quickstart for hosted defaults.
Use /api/patterns/server-api for the backend/frontend split.
Use the SDK when package methods provide the control your app needs.

Existing SDK method compatibility

Existing WavebirdClient methods remain mapped to lower-level compatibility routes: createJob maps to POST /v1/jobs, getDecision maps to GET /v1/decisions/{slot_id}, and sendBeacon maps to POST /v1/beacons.

Do not present these compatibility mappings as the shortest onboarding path.
Use the hosted renderer for browser media rendering whenever possible.
Keep the SDK when a TypeScript wrapper reduces local migration risk.

Breaking behavior to check

Verify key type, allowed origins, server-stored project config, beacon field names, and error envelopes. Compatibility aliases remain in place but should not be used for new examples.

Deprecation timeline

The SDK is not removed in v1. Deprecated helpers remain callable and should emit guidance toward API-first or Script Tag paths.

Concepts

Integration flow

Choose hosted defaults or package control

Back to API docs Contact the team

These pages document the package layer for teams that choose wavebird to control ad requests, decisions, rendering helpers, consent, and beacons directly. Use the API docs for hosted defaults, and use contact only when you want rollout review, enterprise coordination, or help with non-standard integration constraints. Beacon billing rules live in SDK Concepts.