Skip to main content
These docs are public, so they describe only the contract your application needs in order to integrate safely. Public integration model showing the public SDK contract customers can build against and private internals they should not infer.

What is public

You can rely on:
  • Package names, exported SDK APIs, component props, and event names.
  • Public journey states such as ready, routing, gated, and routed.
  • Public sequence phases such as unavailable, scheduled, enterable, participating, settling, granted, and ended.
  • Public stage actions on JourneyView (from view$), such as start(), reroute(), and submitAccessCode(), and per-phase mechanism actions on the routed SequenceView (via RoutedView.sequence), such as enter(), bid(), book(), leave(), and claim().
  • Component customization surfaces: theme, variant, slots, render props, callbacks, locale, and translation overrides.
Render from two public layers: the stage-level JourneyView (exposed by view$) and the routed SequenceView (reached via RoutedView.sequence). Waitlist is a public scheduled-phase attachment (SequenceView.waitlist), not a separate phase or distribution mechanism; it never grants access on its own.

What is not public

Do not build against or document:
  • Private routing decisions or why one consumer received a particular path.
  • Private abuse-prevention or verification mechanics.
  • Internal cache, polling, queueing, retry, or storage implementation details.
  • Internal service topology or endpoint behavior not required by the SDK contract.
  • Any assumed ordering or timing that is not represented by the public state model.
The SDK may ask the user to authenticate, provide an access code, complete an additional verification step, wait, participate, or proceed after admission. Your UI should respond to those states without trying to infer private decision logic.

Safe language for customer UI

Prefer outcome-oriented language:
Instead ofUse
”Verification was triggered by signal X""Additional verification is required"
"Access was denied because of rule X""Access is not available right now"
"The queue let you through because…""You have access to continue"
"Your current attempt count is X""Please try again later”

Handling sensitive runtime values

Admission grants and session-related values should be treated as sensitive runtime data. Use them only for the intended next step in your integration, such as opening checkout or passing control to your backend. Avoid logging them to analytics tools, browser consoles, customer support screenshots, or third-party error reports.