Use case
Add auth and email to Remix
AscendKit's React hooks and components work in Remix, so the sign-in UI drops in directly. The server-side auth runtime is Next.js-only, so a Remix app pairs the client components with a Next.js auth route or verifies AscendKit access tokens in its own loaders. Email, journeys, and surveys then address the same user record. Be clear on that split before you start — it is the part that surprises people.
How it works
- 1. Install the SDKAdd the AscendKit SDK and set your project public key in your Remix app.
- 2. Wire auth into loaders and actionsUse the server helpers to authenticate inside Remix loaders and actions and create usr_ records.
- 3. Send emailSend transactional and lifecycle email from the same project without a separate provider.
What works in Remix, and what does not?
The React hooks and components work. The server-side auth runtime does not — it requires Next.js. Settle that before writing code, because it determines your architecture.
Remix has its own server, so unlike a static Vite bundle you have somewhere to put server logic. What you do not have is AscendKit's auth route handler, which is built on Next.js route conventions. In practice you either run a small Next.js app that owns the auth routes and issues access tokens, or you verify AscendKit access tokens directly in your Remix loaders and actions.
The second option fits Remix well. Loaders already run per request on the server, so verifying a token there and returning user data is idiomatic rather than bolted on.
| Piece | Works in Remix | Notes |
|---|---|---|
| React hooks and components | Yes | Same as Next.js |
| Auth route handlers | No | Next.js route conventions |
| Access token issuance | No | Needs the Next.js runtime |
| Token verification in loaders | Yes | Standard JWKS verification |
| Sending email | Yes | Server-side, secret key |
How do you verify a token in a Remix loader?
The same way any Node backend does — validate the RS256 signature against AscendKit's JWKS. Loaders run on the server, so the secret key is safe there and the check adds no client-side weight.
Cache the key set at module scope rather than creating it inside the loader. Creating it per request adds a JWKS fetch to every navigation, which is exactly the latency Remix is trying to avoid.
Return only what the route needs. A loader that returns the entire claims object leaks more into the client payload than necessary; `sub` and `email` are usually enough.
FAQ
Does AscendKit support Remix as well as Next.js?
The full experience is most polished on Next.js today, but the Better Auth foundation supports additional frameworks like Remix, and framework breadth is expanding by demand.
Is email included for Remix apps too?
Yes. Email is part of the platform regardless of framework, so a Remix app sends from your verified domain without a second vendor.
Related guides
- Add auth and email to React + Vite — the same constraint without a server of your own.
- Add auth to an Express API — the JWKS verification pattern Remix loaders reuse.
Start with one API key
Auth, email, surveys, and journeys share one user record, so you ship this without stitching vendors together.
Start free