Account and auth UI

Compose React SDK login, signup, password recovery, sign-out, and current-user UI without inventing unsupported backend auth flows.

Use this guide when a React storefront needs customer login, signup, password recovery, password update, sign-out, or current-user UI built on @enadhq/enad-react-sdk.

Use SDK package reference for exact component props, hook signatures, runtime implementation details, and package behavior. Use the Auth reference and OpenAPI spec for endpoint paths, request bodies, response fields, token behavior, and error shapes.

Public user surface for this docs track

For the current React SDK track, account/auth UI lives on the grouped public user barrel:

import {
  LoginForm,
  ResetPasswordForm,
  SignOut,
  SignupForm,
  UpdatePasswordForm,
  useUser,
} from "@enadhq/enad-react-sdk/client/user";

This guide stays on shopper-facing login, signup, reset/update password, sign-out, and current-user UI. If exact prop names or return types matter, verify them in the current package reference before shipping code.

What the SDK owns vs what the app still owns

The SDK owns the storefront UI controls and hook entry points. Your app still owns route structure, runtime wiring, security policy, session behavior, backend calls outside the SDK, and support flows.

Use this split when choosing what to implement where:

  • LoginForm, SignupForm, ResetPasswordForm, and UpdatePasswordForm own form UI. Your app owns route existence, post-submit destinations, analytics, support flows, verification policy, and consent policy.
  • useUser owns current-user read state in React UI. Your app owns provider wiring, protected-route decisions, server rendering policy, and related data refresh rules.
  • SignOut owns the shopper-facing sign-out control. Your app owns the landing route, any backend session teardown, and clearing state outside the SDK.
  • Token and cookie mechanics need a working runtime boundary. Your app owns cookie policy, adapter wiring, security settings, and the broader session lifecycle.
  • Backend contract truth lives in Auth API latest, Auth reference, and the Auth playground.

Before mounting account/auth UI, finish the app shell and runtime boundary first. Start with React SDK setup, wire runtime adapters, and keep Auth API latest open for backend contract checks.

Route the common flows deliberately

  • Log a shopper in with LoginForm, then verify backend details in Login user.
  • Register a new shopper account with SignupForm, then verify backend details in Register new user.
  • Start password recovery with ResetPasswordForm, then verify backend details in Create password reset link.
  • Set a new password from a reset token with UpdatePasswordForm, then verify backend details in Change password.
  • Show signed-in account state with useUser, then check package reference for the current hook shape and runtime/session boundary.
  • End the local shopper session with SignOut, then coordinate cookie/session policy and any backend logout or revoke flow your app owns.

Login and signup

Use LoginForm and SignupForm on app-owned routes such as /login and /signup. The SDK gives you the storefront UI surface. Your application still owns what those routes mean in your product.

  • Decide which route the shopper should land on after success.
  • Decide whether email verification is required before the account is treated as fully active.
  • Decide how anonymous cart or wishlist state should merge into a signed-in session.
  • Decide how consent, analytics, and support links are handled.

Treat the Auth reference as the contract source for request and response details. Do not rewrite endpoint fields into page code from memory just because the UI flow is straightforward.

Reset and update password

Use ResetPasswordForm to start recovery and UpdatePasswordForm to complete it with a reset token. The SDK handles the UI boundary. Your app still owns the route work around recovery.

  • Define the route that receives a reset link.
  • Extract the reset token from route or query state.
  • Handle expired-link, already-used-link, and support-recovery UX.
  • Choose the destination route after a successful password update.

Keep password-reset email delivery, token transport, and account-recovery policy at the application layer. Use the Auth reference for the exact reset-link and password-change contracts.

Sign-out

Use SignOut when you want a standard shopper-facing control for ending the current signed-in session in the React UI.

Treat it as the public UI entry point for sign-out, not as the full definition of your session model. Your app still owns the broader session boundary.

  • Decide where the shopper lands next.
  • Clear any app-owned caches, carts, or personalization state that must not survive sign-out.
  • Run any backend revoke or logout step beyond the SDK's local auth/session wiring.

If exact sign-out side effects matter, verify them in the current package reference and your owned backend/session contract rather than assuming them from this guide.

useUser

useUser is the read seam for current shopper account state. Use it for account-aware chrome, account-page shells, and other UI that should branch on whether a shopper appears signed in.

Keep the exact hook return shape in package reference. The example below is intentionally illustrative: it shows the kind of conditional UI this hook enables, not a contract for exact field names.

import { useUser } from "@enadhq/enad-react-sdk/client/user";

export function AccountEntry() {
  const accountState = useUser();

  return <AccountMenu accountState={accountState} />;
}

Before destructuring specific members or relying on loading, refresh, or user-object semantics, verify the current hook reference for this package track. Keep protected-route enforcement, server-side access checks, and durable session policy in your application runtime. If useUser never resolves the expected shopper state, debug the runtime boundary first: provider setup, cookie/navigation adapters, and the app-owned auth/session layer.

Integration checklist

  • EnadProvider is already in place and the SDK stylesheet loads once.
  • Runtime adapters are wired before account/auth UI depends on redirects or cookie-backed session state.
  • The app defines real routes for login, signup, password reset, password update, and any post-success destination it passes into the UI.
  • Exact request and response details come from Auth API latest, Auth reference, or the Auth playground, not from copied prose.
  • useUser is used as UI state, not as the only authorization decision point.
  • Sign-out behavior is coordinated with any app-owned cart, wishlist, cache, or backend session teardown.

Account and auth UI

# Account and auth UI Use this guide when a React storefront needs customer login, signup, password recovery, password update, sign-out, or current-user UI built on `@enadhq/enad-react-sdk`. > Use SDK package reference for exact component props, hook signatures, runtime implementation details, and package behavior. Use the [Auth reference](/reference/auth) and OpenAPI spec for endpoint paths, request bodies, response fields, token behavior, and error shapes. ## Public user surface for this docs track For the current React SDK track, account/auth UI lives on the grouped public user barrel: ```tsx import { LoginForm, ResetPasswordForm, SignOut, SignupForm, UpdatePasswordForm, useUser, } from "@enadhq/enad-react-sdk/client/user"; ``` This guide stays on shopper-facing login, signup, reset/update password, sign-out, and current-user UI. If exact prop names or return types matter, verify them in the current package reference before shipping code. ## What the SDK owns vs what the app still owns The SDK owns the storefront UI controls and hook entry points. Your app still owns route structure, runtime wiring, security policy, session behavior, backend calls outside the SDK, and support flows. Use this split when choosing what to implement where: - `LoginForm`, `SignupForm`, `ResetPasswordForm`, and `UpdatePasswordForm` own form UI. Your app owns route existence, post-submit destinations, analytics, support flows, verification policy, and consent policy. - `useUser` owns current-user read state in React UI. Your app owns provider wiring, protected-route decisions, server rendering policy, and related data refresh rules. - `SignOut` owns the shopper-facing sign-out control. Your app owns the landing route, any backend session teardown, and clearing state outside the SDK. - Token and cookie mechanics need a working runtime boundary. Your app owns cookie policy, adapter wiring, security settings, and the broader session lifecycle. - Backend contract truth lives in [Auth API latest](/apis/auth/latest), [Auth reference](/reference/auth), and the [Auth playground](/apis/auth/playground). Before mounting account/auth UI, finish the app shell and runtime boundary first. Start with [React SDK setup](/react-sdk/latest/setup), wire [runtime adapters](/react-sdk/latest/guides/runtime-adapters), and keep [Auth API latest](/apis/auth/latest) open for backend contract checks. ## Route the common flows deliberately - Log a shopper in with `LoginForm`, then verify backend details in [Login user](/reference/auth/login-user). - Register a new shopper account with `SignupForm`, then verify backend details in [Register new user](/reference/auth/register-new-user). - Start password recovery with `ResetPasswordForm`, then verify backend details in [Create password reset link](/reference/auth/create-password-reset-link). - Set a new password from a reset token with `UpdatePasswordForm`, then verify backend details in [Change password](/reference/auth/change-password). - Show signed-in account state with `useUser`, then check package reference for the current hook shape and runtime/session boundary. - End the local shopper session with `SignOut`, then coordinate cookie/session policy and any backend logout or revoke flow your app owns. ## Login and signup Use `LoginForm` and `SignupForm` on app-owned routes such as `/login` and `/signup`. The SDK gives you the storefront UI surface. Your application still owns what those routes mean in your product. - Decide which route the shopper should land on after success. - Decide whether email verification is required before the account is treated as fully active. - Decide how anonymous cart or wishlist state should merge into a signed-in session. - Decide how consent, analytics, and support links are handled. Treat the Auth reference as the contract source for request and response details. Do not rewrite endpoint fields into page code from memory just because the UI flow is straightforward. ## Reset and update password Use `ResetPasswordForm` to start recovery and `UpdatePasswordForm` to complete it with a reset token. The SDK handles the UI boundary. Your app still owns the route work around recovery. - Define the route that receives a reset link. - Extract the reset token from route or query state. - Handle expired-link, already-used-link, and support-recovery UX. - Choose the destination route after a successful password update. Keep password-reset email delivery, token transport, and account-recovery policy at the application layer. Use the Auth reference for the exact reset-link and password-change contracts. ## Sign-out Use `SignOut` when you want a standard shopper-facing control for ending the current signed-in session in the React UI. Treat it as the public UI entry point for sign-out, not as the full definition of your session model. Your app still owns the broader session boundary. - Decide where the shopper lands next. - Clear any app-owned caches, carts, or personalization state that must not survive sign-out. - Run any backend revoke or logout step beyond the SDK's local auth/session wiring. If exact sign-out side effects matter, verify them in the current package reference and your owned backend/session contract rather than assuming them from this guide. ## `useUser` `useUser` is the read seam for current shopper account state. Use it for account-aware chrome, account-page shells, and other UI that should branch on whether a shopper appears signed in. Keep the exact hook return shape in package reference. The example below is intentionally illustrative: it shows the kind of conditional UI this hook enables, not a contract for exact field names. ```tsx import { useUser } from "@enadhq/enad-react-sdk/client/user"; export function AccountEntry() { const accountState = useUser(); return ; } ``` Before destructuring specific members or relying on loading, refresh, or user-object semantics, verify the current hook reference for this package track. Keep protected-route enforcement, server-side access checks, and durable session policy in your application runtime. If `useUser` never resolves the expected shopper state, debug the runtime boundary first: provider setup, cookie/navigation adapters, and the app-owned auth/session layer. ## Integration checklist - `EnadProvider` is already in place and the SDK stylesheet loads once. - Runtime adapters are wired before account/auth UI depends on redirects or cookie-backed session state. - The app defines real routes for login, signup, password reset, password update, and any post-success destination it passes into the UI. - Exact request and response details come from [Auth API latest](/apis/auth/latest), [Auth reference](/reference/auth), or the [Auth playground](/apis/auth/playground), not from copied prose. - `useUser` is used as UI state, not as the only authorization decision point. - Sign-out behavior is coordinated with any app-owned cart, wishlist, cache, or backend session teardown. ## Related routes - [React SDK latest](/react-sdk/latest) - [React SDK setup](/react-sdk/latest/setup) - [Runtime adapters](/react-sdk/latest/guides/runtime-adapters) - [Import surfaces](/react-sdk/latest/guides/import-surfaces) - [Auth API latest](/apis/auth/latest) - [Auth reference](/reference/auth) - [Auth playground](/apis/auth/playground) - [Troubleshooting](/start/troubleshooting)