jamauth Preview

Lock a page. Choose who gets in.

Add a magic-link login wall to a page on Netlify, Vercel, Render, or any site where you can run a small server-side check. Start with an approved-email list; Stripe customer gates and custom rules are in preview. No auth backend. No user database of your own.

what it is

Two small pieces you paste into a page. A login widget proves who someone is. A server-side gate decides whether they get in. That's the whole contract — nothing to rebuild your app around.

01  paste the login widget

Drop it where the login should appear. JamAuth sends the email, verifies the link, and creates the session.

<div id="jamauth-login"></div>

<script
  src="https://api.jamauth.com/jamauth.js"
  data-client-id="YOUR_CLIENT_ID"
  data-host="https://api.jamauth.com"
  data-target="#jamauth-login"
></script>

02  protect the route

Your protected route asks the gate one question before it opens: is this signed-in person allowed?

/.netlify/functions/protected-page

The starter ships the full callback, session check, and protected route as a working reference.

who gets in

approved emails

available now

Add the addresses from the dashboard. No code, no Stripe, no deploy. Good for beta lists, client previews, and private files.

stripe customers

in preview

Sell access through Stripe — a paid, active customer gets in automatically. Stripe runs checkout and holds the cards, so you never build billing or touch card numbers. Wiring this up now.

your own rule

Point the gate at your own logic: a role, a plan, a license key, a record in your API. If your system answers yes or no, the gate enforces it.

The gate stays the same. Only the answer changes.

where it runs

The login script goes anywhere you can add a tag. The gate — the part that actually refuses access — runs wherever you can run a small server-side check: Netlify, Vercel, Render, or your own server.

Hosts without a backend of their own (Webflow, WordPress, plain HTML) work too, with a serverless route added alongside. A script on its own can hide a page; it can't protect one.

removing it is three steps

  1. Delete the login widget.
  2. Delete the callback.
  3. Point your protected route somewhere else.

Your content, your Stripe account, and your access rules stay where they are — with you. There's no user database to migrate out of.