Migration
Migration from pre-transition SDK
Existing SDK integrations keep working, but new rollouts should prefer the Server API default first.
New default path
New Server API integrations should call POST /v1/placements?wait_ms=1500 and render with the hosted render.js flow instead of rebuilding the SDK job-plus-decision sequence in app code.
- Use /api/quickstart when starting a new integration.
- Use /api/patterns/server-api for the backend/frontend split.
- Keep the SDK only when package methods reduce migration risk.
Existing SDK method compatibility
Existing CslClient 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.
API first, Script Tag second, SDK third
These pages are the advanced package layer for teams that intentionally choose @csl/wrapper-sdk. Primary onboarding still lives in the API docs, and browser-first installs should start with the Script Tag. Use contact only when you want rollout review, enterprise coordination, or help with non-standard integration constraints. Beacon billing rules live in SDK Concepts.