Stytch Signup Enrichment: Turning Passwordless Signups Into Growth Signal

A magic link tells you almost nothing on its own

Stytch is built around removing passwords: magic links, one-time passcodes over email or SMS, passkeys, and OAuth, plus a B2B layer with organizations, members, and SSO for teams that need it. That is good news for conversion. Nobody abandons a signup form because they forgot a password, because there was never a password to forget.

It is bad news for anyone trying to figure out who just signed up. A magic-link click carries an email address and a timestamp. An OTP carries a phone number or email and nothing else. There's no company field, no job title, no "how did you hear about us" dropdown, because Stytch's whole pitch is that you don't need those fields to get someone into your product.

So the enrichment problem for Stytch users looks different from the enrichment problem for a form-based signup. You're not stripping down a bloated payload. You're starting from almost nothing and building context after the fact, without touching the parts of the flow that make Stytch worth using in the first place.

Groful runs this as a background process: PLG signup enrichment that resolves company and role context from an email or phone number, scores the result against your ICP, and only then decides whether the record deserves a personalized onboarding path or a sales-assist workflow. None of it touches the auth flow itself.

What actually changes with a passwordless product

Two things about Stytch signups make the enrichment approach different from a standard email-and-password form.

First, the identifier you get back isn't always an email. A user can authenticate with SMS OTP and never give you an email address at all, especially on consumer-leaning products. If your enrichment pipeline assumes "email in, company out," phone-only signups fall through untouched. You need a resolution path for both identifier types, and you need to accept that phone-only signups will often stay unresolved until the user connects an email, joins an organization, or shows up again through a different channel.

Second, Stytch's B2B product gives you organization and membership data for free once a user joins or creates one. If your app uses Stytch's Organizations API, you already know that a user belongs to "Acme Corp" before any enrichment call runs. That's a gift, so use it. Skip company-name guessing entirely for these users and spend the enrichment budget on filling in the details Stytch doesn't give you: industry, headcount, funding stage, and who else at that company might be a fit.

The minimum payload worth sending

Keep the enrichment trigger event small and specific to what you can actually act on:

• Internal user ID and organization ID, if the user has joined or created a Stytch organization.
• Email address when available, plus whether it was the verified login method.
• Phone number when the login method was SMS OTP and no email exists yet.
• Login method: magic link, OTP, passkey, or OAuth provider.
• Signup or first-login timestamp, referrer, and campaign data if you capture it.
• Organization name and role from Stytch's B2B objects, when present.
• A request ID for idempotency, because retries on background enrichment jobs are common.

Everything else (company size, industry, seniority, ICP score, confidence, teammate matches) comes back from the enrichment layer, not from the auth event.

A Stytch enrichment playbook

1. Enrich after the session is verified, never before

Stytch's flows involve a round trip: send the magic link or OTP, wait for the user to complete it, then create the session. Enrichment should trigger on session creation or the first authenticated request, not on the initial "send code" request. Otherwise you'll enrich people who never actually finished signing up, which wastes API calls and pollutes your data with abandoned attempts.

2. Give phone-only signups a real path, not a dead end

If a user authenticates by SMS OTP and never supplies an email, don't just mark the record "unenrichable" and move on. Look for a company match through the phone number's carrier-linked metadata where your provider supports it, or hold the record in a pending state until the user adds a work email, gets invited to an organization, or logs in again through a channel that carries more signal. A phone-only user isn't necessarily low value. They're just under-identified for now.

3. Trust Stytch's own organization data before you guess

When a signup already carries a Stytch organization ID and name, don't run a separate company-resolution step to re-derive something you already know. Use that org data as the anchor and spend the enrichment call on enrichment: industry, size, funding, and personal email resolution for any members who joined with a Gmail or Outlook address despite being part of a real company account.

4. Score fit and activation as two separate numbers

An ICP score for a Stytch signup should weigh company size, industry, role, and how closely the account resembles your best customers. Activation should track what the user actually did: created an organization, invited a teammate, connected a core integration, hit a usage milestone. Collapsing these into one score hides the difference between "great-fit company that hasn't tried the product yet" and "already active user who isn't actually who you sell to."

That split gives you a routing table instead of a single number:

• High fit, high activation: route to product-led sales or a founder-led follow-up.
• High fit, low activation: send lifecycle nudges tied to the feature that matters most for that persona.
• Low fit, high activation: leave it self-serve. Learn from the usage pattern instead of trying to sell into it.
• Low fit, low activation: nurture lightly, or don't spend effort on it at all.

5. Watch for multiple members joining the same organization

Because Stytch's B2B objects track organization membership directly, you get a cleaner signal for expansion than you would from a pile of personal-email guesses. If three people join the same Stytch organization within a couple of weeks, that's a stronger expansion signal than three unrelated signups that happen to share a resolved company domain. Teammate discovery can add the people who haven't signed up yet but clearly belong to the same account, based on company match and role.

6. Send results where your team already looks

Enrichment that lives in a table nobody queries doesn't change anything. Route the output into product analytics for segmentation, your CRM for accounts that clear the routing bar, Slack for high-fit alerts, and a review queue for anything in between. If your onboarding flow personalizes based on role or company size, that data needs to land before the user's second session, not a week later.

An example routing model

A B2B SaaS product using Stytch's Organizations product for team accounts might set up something like this:

• Default: every new user starts in standard onboarding, whether they arrived by email, OTP, or passkey.
• Org-anchored fast path: users who joined an existing Stytch organization skip company guessing and go straight into enrichment for firmographic detail.
• Personalized onboarding: users with resolved role and company-size data see onboarding steps relevant to their use case.
• Sales review: high-fit organizations with real product usage, not just a signup, enter a human queue.
• Expansion watch: organizations gaining members over time get flagged for account-level attention, independent of any single user's activation.
• Pending resolution: phone-only or low-evidence signups sit in a holding state until more signal arrives.

Keep the first version simple enough that anyone on the team can explain why a given record ended up where it did.

Checklist before you ship it

• Enrichment fires on verified session creation, not on OTP or magic-link send.
• Phone-only signups have a defined path instead of being silently dropped.
• Existing Stytch organization data is used directly, not re-derived through guesswork.
• ICP fit and product activation are stored and reasoned about separately.
• Personal-email members inside a real organization get resolved, not ignored.
• Multi-member organization growth is tracked as an expansion signal.
• Routing rules are documented well enough that a teammate can audit any given outcome.

How to tell if it's actually working

Track the percentage of Stytch signups that resolve to a usable company record, split by login method, since OTP and magic-link users will likely resolve at different rates. Watch activation by ICP tier, sales-assist acceptance rate for routed accounts, and how often an organization gains a second or third member after the first signup. If phone-only signups never resolve and never convert, that's a sign to either collect an email earlier in a targeted way or stop spending enrichment budget on that segment.

Where this leaves you

Stytch removes friction from the login screen. Enrichment is how you get the context back without adding it there. Start with the verified-session-created event. Enrich it, then use the result in one place you can measure, like onboarding personalization or a sales review queue gated on both fit and behavior. Add organization-based expansion tracking once the basics are solid.

Groful builds this for teams running signup enrichment, product-led sales, and growth-stack routing on top of modern auth providers. Browse the Groful blog for related playbooks, check pricing, or get in touch if you want help mapping Stytch's session and organization events into an enrichment workflow that fits your funnel.