Summary
This document explains how OTP sign‑in works in Loudcrowd’s mobile SDKs, what happens on the backend to authenticate creators, and how access tokens are stored and shared with other components.
What the OTP component is
A drop‑in screen that lets a creator:
1. Enter their email → receive a one‑time code, and
2. Enter the code → get signed in to creator tools (Creator Widget, Storefront editing, ShopWith attribution).
No custom endpoints are required from your engineering team.
User flow (at a glance)
1. Email submit → the component calls Loudcrowd’s OTP endpoint to request a code.
2. Code delivery → code is sent to the email (time‑limited, single use).
3. Code verify → the component submits the email + code to Loudcrowd.
4. Token issued → on success, Loudcrowd returns `{ creatorId, token, expiresAt }`.
5. Session updated → the SDK writes `creatorId` and `creatorToken` into the shared Loudcrowd session; all components immediately have access.
Token storage & lifecycle (in the SDK)
Refresh & expiry: Components check expiry and prompt re‑auth when needed. Tokens can be revoked server‑side.
Scope: Tokens are only read by Loudcrowd WebViews through the SDK bridge—not exposed to other app code unless you intentionally read them.
How other components see the session
After verification, the SDK broadcasts session updates to all Loudcrowd views/overlays:
Storefronts can adapt UI for authenticated creators and inline editing.
Creator Widget is unlocked so creators can add products directly on the PDP.
Access is via a stable state interface (e.g., `window.loudcrowd.native.getState()` in WebViews); you don’t pass tokens around manually.
Client responsibilities
Call `Loudcrowd.configure(...)` at app launch.
Render the OTP view when creators click on the sign in button (found on the Storefront view).
Handle basic UX (show errors, resend button) — the component provides defaults.