Because none of these flows is one request.

Signing up is a POST, an email, a verification link that lands on a different origin, a redirect carrying a token in a URL fragment, and a token to store. A session is a JWT that expires in fifteen minutes and has to be renewed before it does, from a timer that survives a backgrounded tab. A checkout is a redirect to Stripe, a return to a page that knows which order came back, and a webhook that may arrive after the customer does.

The kit is the accumulated shape of those flows, against restheart-accounts and restheart-stripe as RESTHeart Cloud runs them. It has no dependencies of its own and no opinion about your framework.

An adapter is a wrapper, not a fork: the same functions, exposed the way that framework expects state to arrive. Payments are a separate surface from auth in each of them, because a subscription is not a session — it loads on sign-in, reloads on team switch, and stays untouched when the service has no stripe plugin.

Angular and Vue want the core installed alongside; React and Vue pull it in as a regular dependency. Each package’s README has the exact line.

Angular, in app.config.ts:

React, near the root:

Vue, in main.ts:

In all three the session is restored once at start-up, before the first guard runs, so a page reload does not bounce a signed-in user to the login page. Until that settles, initializing is true — render a spinner on it, not a redirect.

The token is a JWT with a fifteen-minute life. The kit schedules a renewal at 80% of its TTL, so a tab left open stays signed in without the app or the user noticing. If it does expire — a sleeping laptop, a tab backgrounded for an hour — the next call gets a 401 and the session is cleared: the user sees "signed out" rather than a silent failure.

Accounts — register, verify, login, logout, checkSession, getUserInfo, renewToken, forgotPassword, resetPassword, changePassword, updateProfile. The flows documented under Sign-up, OAuth & Invitations, with the redirects and token deliveries already handled.

Teams — getTeams, switchTeam, createTeam, listTeamMembers, updateMemberRole, removeMember, and the invitation half: invite, getInvitation, activate, acceptInvite, resendInvite. Switching teams mints a new token, since the team is a claim in the old one.

Consents — acceptConsents, for the terms-and-privacy pattern. Pairs with Guards, which is what makes acceptance mandatory server-side rather than a dialog the client can be talked out of showing.

Payments — getPlans, createCheckoutSession, openBillingPortal, getSubscription, waitForSubscription, and seat licences with getLicenses / grantLicense / revokeLicense. For a shop rather than a subscription: getCatalog, createOrder, getOrder, waitForOrder, readOrderRef. No Stripe.js and no publishable key — every Stripe page is hosted, so the kit hands you a URL to navigate to. See Stripe Billing for the service side.

waitForOrder exists because the customer’s browser usually beats Stripe’s webhook back to your site. It rejects with a distinct WaitTimeoutError, so a late webhook renders as "still confirming" rather than as a failed payment.

Errors arrive as { status, message } — an ApiError, thrown, with the server’s own sentence in it.

register sends whatever you give it. If the service’s users collection has a JSON Schema, extra fields are validated against it; if it has none, the server silently drops them and still answers 201. A profile field that never appears is usually this, and not the kit.