Two Roles Pattern

In most real implementations, you create these objects in order:

1. Customer session record (server-side)
   • session_id
   • generated PIN
   • status (active/revoked)
   • expiry timestamp
2. Customer token (role_type=1)
   • used by customer browser SDK to start/share session
3. Agent token (role_type=2)
   • created after PIN validation
   • used to load agent desk iframe or custom agent UI

PIN Source of Truth

In practice, the PIN you should hand to agents is the value emitted by customer SDK event:

• session.on("pincode_updated", ...)

Do not rely on placeholder/provisional PIN values from pre-start backend records for user-facing flows. Always show one clearly labeled PIN in UI (for example, “Support PIN”) and reuse that same value in agent links.

Recommended Endpoint Split

• POST /api/customer/start -> create session + customer token + PIN
• POST /api/agent/connect -> validate PIN + issue agent token
• POST /api/session/revoke -> end session
• GET /api/session/list -> operational visibility

See:

• Get Started
• Authorization (official)