Clerk Alternative: A Pay-as-You-Go OTP API for Login-Only Teams

Clerk is one of the best full-stack auth platforms out there. It gives you drop-in React components, a polished user dashboard, organizations, SSO, and MFA — all wired up for you. If you're building a B2B SaaS with a long list of identity requirements, it earns its price.

But a lot of teams show up to Clerk needing exactly one thing: send someone a code, check the code, log them in. Once they're a few months in, they realize they're paying a per-user monthly bill for a login flow that's literally two HTTP calls.

This post is an honest look at Clerk for teams that only need OTP or magic links, why so many are shopping for a pay-as-you-go OTP API, and how a headless verification API like otpmagiclink.com compares. If you also want the tutorial, jump to the Next.js OTP verification walk-through. If Auth0 or Twilio Verify are on your shortlist too, we've done the same breakdown for Auth0 and Twilio Verify.

Who this comparison is for

This post is aimed at teams looking for a Clerk alternative for OTP-only auth — usually startups and indie hackers who signed up for Clerk because the components looked great in the demo video, but who never actually used organizations, SAML, or the hosted user dashboard. If you need the full Clerk platform (Orgs, SCIM, prebuilt UI components), stay put. Everyone else can probably run a much lighter stack for a fraction of the monthly bill.

Where Clerk shines

• Best-in-class React components. <SignIn /> and <UserButton /> genuinely save weeks if you want a polished auth UI without designing it.
• Organizations and B2B primitives. Invitations, roles, and org switching are all built in and hard to replicate.
• Managed session layer. Clerk issues, rotates, and validates the session for you.
• SOC 2 today. If your buyer's security team needs the certificate, that's already done.

If you're actually using all of that, Clerk is worth the price. Most teams shopping for an alternative aren't.

Where teams get frustrated

1. MAU pricing punishes users who log in infrequently

Clerk charges per monthly active user. That's fine when every user pays you monthly too. It's less fine when you're building a consumer app where a user might log in once a month, verify, and disappear until next month. You're paying for a full auth seat every time.

A pay-as-you-go OTP API only charges you for the verification event itself — the code send + check pair. A user who logs in once costs the same as one who never comes back. The bill scales with actual login activity, not with how many rows your users table has.

2. You're using 10% of the product

Clerk has organizations, memberships, invitations, roles, permissions, sessions, JWT templates, webhooks, and a hosted user profile page. If your login flow is "email + OTP → set a session cookie," you're touching maybe two of those tabs. Every new engineer on your team has to learn the whole platform to avoid stepping on it.

A focused headless OTP API has three concepts: a project, an API key, and a verification. You can onboard someone to the whole surface area in an afternoon.

3. The UI components are a benefit until they're a lock-in

Clerk's <SignIn /> component is fantastic for the first week. Then you realize you want the OTP screen to match your brand exactly, or you want copy that says "check your inbox" instead of "verify your email," or you want to route the user somewhere different after login. Each of those means dropping down to the headless API anyway — at which point you're paying platform prices for API-only usage.

If you're going headless in the end, you might as well start with a headless verification API and skip the round-trip.

4. Testing OTP flows against Clerk in CI is painful

Clerk supports test emails and test phone numbers with fixed codes, which works for basic happy-path tests. But you can't drive the same code path as production without mocking, and every real code you send in CI counts against your Clerk usage. Teams end up either running an "auth-lite" test setup or paying for staging usage.

A verification API built around a sandbox inbox lets your Playwright / Cypress / Jest tests pull the OTP back through the same API a real user would use. Free forever, same code path as production.

Feature comparison

Why pay-as-you-go beats per-MAU for OTP-only auth

Per-MAU pricing was invented for a world where every user is worth a subscription seat. It made sense for enterprise identity products where every "user" is an employee logging in daily. For consumer apps and login-only use cases, it stops making sense fast.

Consider two teams:

• Team A: a consumer app with 100k users. The average user logs in twice a month. That's 200k monthly logins.
• Team B: an internal admin tool with 500 users. Every user logs in daily. That's ~10k monthly logins.

Under Clerk's per-MAU pricing, Team A pays 200× what Team B pays even though they're only doing 20× the actual auth work. Under a pay-as-you-go OTP API charging per verification, Team A pays 20× more than Team B — which matches the actual usage.

The pattern isn't new. Stripe's own usage-based billing documentation explains why per-event pricing scales better for consumer products. OpenAI, Twilio, and AWS use per-event pricing for exactly this reason. Charging per-MAU for auth is one of the last holdouts, and it's mostly historical — auth vendors picked the model when their customers were enterprise buyers.

If you're building anything except a B2B SaaS with high per-user LTV, per-verification pricing is almost always the better fit.

When to stay on Clerk

• You're building a B2B SaaS and actively use Clerk's organizations, invitations, or SCIM features.
• You need Clerk's hosted UI components and don't want to build a login page.
• Your users log in frequently enough that the MAU model works out.
• Your buyer's security team requires SOC 2 today.

When to switch

• Your login flow is basically just OTP or magic link, and 90% of Clerk's dashboard is unused.
• Your Clerk bill scales faster than your revenue because your users log in infrequently.
• You've already dropped to Clerk's headless API and are paying platform prices for API-only usage.
• You want your CI to run the real OTP flow, not a stubbed test-mode code.

Migration path from Clerk

Moving off Clerk for OTP-only auth is smaller than most teams expect, because the API you have to swap is only two calls: create a verification, then check a code. Here's the pattern most teams follow:

1. Keep your existing users table. Clerk's user database is separate from your app's users — most teams already have an email column keyed to their own user IDs. Nothing about your user model needs to change on your side.
2. Sign up for a sandbox project on otpmagiclink and drop the new API key into a feature-flagged branch. See the Next.js OTP verification tutorial for exactly what the two API calls look like.
3. Replace <SignIn /> (or signIn.create) with a simple email + code form. Two textboxes and a submit button.
4. Wire the check into your session layer. If Clerk was issuing your sessions, you'll now issue them yourself with Auth.js, iron-session, or a plain JWT. Existing user records don't change.
5. Flip the feature flag for a small group (say 5% of new signups) and compare success rate against Clerk in your analytics.
6. Roll it out to everyone once numbers look good and cancel your Clerk subscription. Export any user profile data you were storing in Clerk's publicMetadata via their Backend API and copy it into your database.

Most teams get through this in one or two sprints. The parts that took the longest with Clerk — customizing components, wiring up webhooks, tuning the user profile UI — just aren't parts of the new stack.

FAQ

Is Clerk free for small projects?

Yes, Clerk has a free tier. It's usually generous enough for a side project or early beta, but the paid tier kicks in and the cost climbs quickly with monthly active users after that. If you're a B2B SaaS with paying customers each contributing revenue, the math still works. If you're a consumer app with a long tail of infrequent logins, a pay-as-you-go OTP API usually comes out cheaper by an order of magnitude.

Can I keep my users if I move off Clerk?

Yes. Your app almost certainly already has a users table — Clerk doesn't own your email or user_id columns. When you switch, you keep the users, keep the IDs, and just change how they authenticate. Any user profile data you were storing in publicMetadata or privateMetadata can be exported from the Clerk Backend API and copied into your own database.

Does otpmagiclink have React components like Clerk?

No, and that's on purpose. otpmagiclink is a headless OTP API — you build the UI, we handle the verification. If you want prebuilt components, pair it with an Auth.js setup and Shadcn UI form primitives. Most teams find that a two-input login page is easier to design than they expected.

What about organizations and B2B roles?

That's an app-level concern, not a verification-API concern. Most teams handle it with an org_id and a role column on their users or memberships tables and a middleware check. otpmagiclink isn't a user-management platform, and that's the point.

How does pay-as-you-go OTP pricing actually work?

You pay a flat rate per completed verification — retries don't cost extra, expired codes don't cost extra, and there's no tier jump as you scale. If your app does 1,000 verifications this month, you pay for 1,000 verifications. If it does 1,000,000 next month, the per-verification rate is exactly the same. No MAU multiplier, no team-size tier, no feature gate at higher volume.

How does this compare to Auth0 or Twilio Verify?

We've done both breakdowns: see the Auth0 alternative post and the Twilio Verify alternative post. Short version: Auth0 is heavier on enterprise identity, Twilio Verify is stronger on global SMS, and Clerk is stronger on B2B components. otpmagiclink is focused on the OTP + magic-link primitive, priced per verification.

Ready to try it?

Start a free sandbox project on otpmagiclink.com — no card required — or read the Next.js OTP verification tutorial for the two API calls you actually need. If you're comparing multiple options, the fastest way to make a call is to swap one flow (login or signup) behind a feature flag and watch the numbers for a week.