SuperTokens Signup Enrichment: A PLG Playbook for Dev-First SaaS

SuperTokens gets you a session. It doesn't get you a company.

SuperTokens exists because teams got tired of Auth0's pricing curve and didn't want to hand-roll session management, email verification, and social login from scratch. It's open source, self-hostable if you want that, and built by developers who clearly got annoyed at how bloated most auth SDKs are. That's the appeal: a login flow that does exactly what it says and nothing else.

The tradeoff is that "nothing else" includes company data. A SuperTokens signup gives you a user ID, an email, maybe a name if you added that field, and a session token. It does not tell you whether the email belongs to a solo developer testing your API on a Tuesday night or the fifth engineer at a company that's about to standardize on your product. SuperTokens was never trying to answer that question. It's an auth library, not a growth tool.

That gap matters more for SuperTokens users than for teams on heavier platforms, because SuperTokens tends to get picked by exactly the kind of product where this decision is hardest to make by hand: developer tools, infrastructure products, API-first SaaS, open-source-adjacent companies with high signup volume and low willingness to add friction. These are products where a ten-second signup form is a competitive advantage, which means growth and sales teams get almost nothing to work with at the moment someone joins.

Groful sits next to SuperTokens to close that gap. It takes the email and user ID SuperTokens already captures, resolves the company and person behind it, scores the account against your ICP, and pushes a routing decision to your team before the signup even finishes its first onboarding step. See how that fits a self-serve motion through PLG signup enrichment or product-led sales.

Why dev-first signup flows are the hardest to enrich well

Three things make SuperTokens-style signups harder than a typical B2B form, and all three come from the same source: developers building for developers tend to strip out anything that isn't strictly necessary.

The first is email quality. A meaningful share of SuperTokens signups come from personal Gmail or Outlook addresses, sometimes intentionally (a developer wants to try the product before looping in a company account) and sometimes because the product is used inside a larger org under a personal login by habit. Resolving these correctly takes more than a domain match.

The second is missing fields. Because SuperTokens ships as an unopinionated auth core, most implementations collect only email and password (or a social login token) at signup. There's no company name field, no job title, no team size dropdown, because someone on the team decided, correctly, that adding one would hurt conversion. That decision is good for signups and bad for anyone trying to understand who just signed up.

The third is signal timing. Developer-first products often see real usage before real intent. Someone might spin up an account, hit the API a few times, and go quiet for two weeks before coming back with a teammate. A single enrichment pass at signup misses that arc entirely.

The minimum useful SuperTokens enrichment payload

Send enrichment from your backend the moment session.create or your post-signup callback fires, using only what SuperTokens already has:

• SuperTokens user ID and the recipe used (email/password, passwordless, or a third-party/social provider).
• Email address and, for social logins, the provider's verified-email flag.
• Signup timestamp and IP-derived region, if you're already logging it for other purposes.
• Any UTM or referrer data captured before the SuperTokens session started.
• A stable internal user ID your product database can join against.

What should come back: resolved company name and domain, industry and employee range, an ICP score with a confidence value, personal-email resolution status, and a recommended action, whether that's self-serve, personalize onboarding, watch for expansion, or flag for sales. None of this requires touching the SuperTokens recipe implementation or asking the user for anything extra.

A playbook for enriching SuperTokens signups without slowing anything down

1. Enrich from an override on the backend recipe, not the frontend SDK

SuperTokens lets you override the signUp or consumeCode (for passwordless) function on the backend recipe. That's the right place to trigger enrichment, not a frontend callback. It keeps your enrichment API key server-side, catches every signup path including social logins, and runs whether the user came through your hosted UI or a custom frontend built on the SuperTokens SDK.

Fire enrichment asynchronously after the override returns the session, not before. SuperTokens is fast because it doesn't do much extra work at signup; don't undo that by making the user wait on a third-party API call.

2. Treat personal-email signups as the default case, not the exception

Because so much SuperTokens signup traffic starts with a Gmail or Outlook address, build your default enrichment path around resolving personal email signups rather than treating it as a fallback branch. Use name (if collected), IP-derived location, and any teammate invites that happen later as corroborating signals, and keep the confidence score honest. A personal-email match should never carry the same confidence as a corporate-domain match.

3. Re-run enrichment when usage crosses an activation threshold, not just at signup

Because dev-first signups often precede real intent by days or weeks, a single enrichment pass at account creation will miss the moment a trial becomes real. Pick one or two usage events that correlate with genuine adoption (first successful API call, first production key generated, first teammate invited) and re-trigger enrichment when they fire. This catches the accounts that looked unremarkable at signup and turned into something worth a sales conversation two weeks later.

4. Watch for multiple SuperTokens users resolving to one company

Because SuperTokens has no built-in organization or workspace concept unless you build one yourself, a five-person team evaluating your product often shows up as five unrelated user records. Resolve each signup to a company domain and roll them up before scoring, the same logic covered in user-to-account matching. Without this step, a strong account gets scored five separate times at whatever the weakest individual signal happens to be, instead of once at the strength the whole account actually represents.

5. Route on ICP fit plus activation, not either alone

A high ICP score with zero product usage two weeks in is a good account that hasn't found value yet, not a sales-ready lead. A low ICP score with heavy API usage might be a smaller company that's still worth a self-serve growth play. Cross both signals before deciding where an account goes, instead of routing on ICP score alone.

Example routing rules for a SuperTokens-based product

Corporate email, high ICP fit, no usage yet

Personalize onboarding emails and in-app messaging for the resolved company and likely use case. Hold off on sales outreach until there's an activation signal.

Personal email, resolved to a mid-market or larger company, active API usage

This is the profile developer tools miss most often, because the email looks unremarkable. If usage is real and the resolved company fits your ICP, flag for a light-touch, developer-relations-style outreach rather than a standard sales sequence. Cold enterprise sales language tends to fall flat on this segment.

Multiple users resolving to the same domain within a short window

Treat this as a team-adoption signal regardless of individual ICP scores. Consolidate into one account record and route to whichever team owns expansion motion.

Low fit, low usage, thirty days out

Leave in self-serve nurture. Revisit only if a new signal (teammate invite, usage spike, upgrade page visit) appears.

Measuring whether SuperTokens enrichment is working

Start with coverage: what share of signups resolve to a real company, and what share stay stuck at "personal email, low confidence." A dev-first product with a lot of unresolved personal-email signups isn't necessarily broken, since some of that traffic is genuinely individual developers, but a coverage rate that never improves usually means the resolution logic needs a second signal beyond domain matching.

Then track how often the activation-triggered re-enrichment step changes a routing decision. If accounts rarely move from "watch" to "flag for sales" after a usage threshold fires, either the threshold is set wrong or the usage events you picked don't actually correlate with buying intent. Adjust the threshold before adding more enrichment sources.

Finally, check account consolidation numbers: how many resolved companies had two or more separate SuperTokens users roll up into them, and how that group's conversion rate compares to single-user accounts. If multi-user accounts convert meaningfully better, and they usually do, that's the strongest argument for prioritizing the consolidation step over any other single improvement.

Implementation checklist

• Trigger enrichment from a backend recipe override, never the frontend SDK.
• Default to careful personal-email resolution instead of treating it as an edge case.
• Re-run enrichment on activation events, not just at signup.
• Roll up multiple SuperTokens users into one company record before scoring.
• Route on ICP fit combined with usage, not ICP score alone.
• Track coverage, re-scoring impact, and account consolidation rate monthly.

Where this leads

SuperTokens does exactly what a good auth library should: get out of the way. That's precisely why the growth and sales side of a SuperTokens-based product needs enrichment doing the work the signup form deliberately doesn't. The teams that get the most out of it treat every session as a starting point, not an ending point, and let usage events tell them when to look again.

If your product runs on SuperTokens and you want signups turned into ICP-scored, sales-ready context without adding a single field to your login flow, see how PLG signup enrichment works, check pricing, or talk to Groful about connecting it to your current signup flow.