Migration

Migration from pre-transition SDK

Existing SDK integrations keep working, but new rollout should prefer Server API first and Script Tag second.

Old SDK method to new API

CslClient.createJob maps to POST /v1/jobs. CslClient.getDecision maps to GET /v1/decisions/{slot_id}. CslClient.sendBeacon maps to POST /v1/beacons.

Use direct REST when you do not need SDK convenience types.
Use Script Tag for browser slots.
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

API first, Script Tag second, SDK third

Back to API docs Contact the team

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.