Reference
This section is the stable navigation layer for the current SDK reference. It is designed for readers who already understand the main flow and now need the concrete client surface, types, runtime notes, and the FAQ in one place.
Quick answer
If you are integrating now, open CslClient first and keep the Types page nearby. Those two pages cover most implementation questions.
The route note and FAQ belong later in the reading order. They clarify boundaries, but they should not replace the main client and type reference.
Browse the reference
Methods
The answers below stay close to the released SDK surface and the documented evidence behind it.
CslClient
Start here for the current app-facing client surface, including the core methods for jobs, decisions, generation events, and beacons.
Types
Browse the request, response, lifecycle, configuration, and error types that shape the released integration contract.
React components
The answers below stay close to the released SDK surface and the documented evidence behind it.
Routes
Read the public wrapper and proxy-facing route map without confusing proxy compatibility with the CslClient method family.
FAQ
Use the developer FAQ for rollout boundaries, current package status, and guidance on which path to start with.
Suggested reading order
- Read
CslClientto understand the main app-facing surface. - Use the type reference while wiring requests, responses, and lifecycle events.
- Use the route reference to understand the public wrapper and proxy-facing boundary.
- Use the FAQ for rollout and package-status questions.
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.