# Migration from pre-transition SDK

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

Move SDK-first integrations to API-first or Script Tag paths.

## 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.