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 WavebirdClient 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.
WavebirdClient
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 WavebirdClient 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
WavebirdClientto 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.
Choose hosted defaults or package control
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.