What do you need before someone can sign in?

A web app typically uses two libraries. One runs in the browser to show or connect the sign-in screen. The other runs on your app’s server and talks to SuperTokens Core, the service that keeps accounts and sessions.

Choose the browser and server libraries that fit your app and set the web and server addresses. You can use a ready-made screen or build your own. If you run Core yourself, plan for PostgreSQL and keep both Core and the database accessible only from trusted server components.

Can a signed-in customer open someone else’s booking?

A session helps your server recognize a signed-in customer on later requests. Your server still needs to check whether that customer owns the booking or has another valid reason to open it.

Put the check where the app reads or changes the booking. Hiding a button is useful for navigation, but the server needs to make the same access decision even when the page sends the request directly.

How do you check recovery without contacting customers?

Use a disposable web app, test Core and sample bookings. Before opening the app, confirm where the app stores bookings and where Core stores accounts and sessions. Both must use disposable databases. Check that the app uses the test Core and its email-and-password flow. Route that flow’s reset messages to a test inbox that catches them without delivering them. Leave other sign-in and message providers disconnected. Use a paper walkthrough if you cannot verify the setup.

Use two fictional accounts
Sign in to each account in a separate browser session. Give the first account a sample booking and confirm the second cannot read or change it.
Request one reset
Use the first account’s test address. Check that the captured link opens the reset screen in the test copy, set a new test password and confirm that the first account can sign in again.
Repeat the access check
Check that the recovered account can still open its own sample booking and that the other account is still denied.

What do you pay for on managed and self-hosted setups?

Managed pricing counts unique logged-in users per month, including new signups. The published Core offer is free under 5,000 monthly active users and lists $0.02 per monthly active user. Check the threshold and any paid features before relying on the estimate.

The self-hosted open-source features have no active-user fee. You still run the service and its database, handle updates and recovery, and pay for any separately priced features or message delivery you use.

What should you test before moving accounts?

Keep a way to match old account IDs to the new IDs so a returning customer can still find their records. Check which password formats the destination can read and how social sign-in accounts will map.

SuperTokens documents importing accounts and handling existing sessions as separate migrations. For a self-hosted setup, keep a restorable database backup and its configuration. For a managed setup, confirm what you can retrieve before committing to the move. Try the plan with sample accounts before relying on it for customers. Restrict access to account backups and password hashes, just as you would for other credentials.