/
Contact usSee pricingStart building
Node
​

    About Stytch

    Introduction
    Integration Approaches
      Full-stack overview
      Frontend (pre-built UI)
      Frontend (headless)
      Backend
    Migrations
      Migration overview
      Migrating users statically
      Migrating users dynamically
      Additional migration considerations
      Zero-downtime deployment
      Defining external IDs for users
      Exporting from Stytch
    Custom Domains
      Overview

    Authentication

    DFP Protected Auth
      Overview
      Setting up DFP Protected Auth
      Handling challenges
    Magic Links
    • Email Magic Links

      • Getting started with the API
        Getting started with the SDK
        Replacing your password reset flow
        Building an invite user flow
        Add magic links to an existing auth flow
        Adding PKCE to a Magic Link flow
        Magic Link redirect routing
    • Embeddable Magic Links

      • Getting started with the API
    MFA
      Overview
      Backend integration
      Frontend integration
    Mobile Biometrics
      Overview
    M2M Authentication
      Authenticate an M2M Client
      Rotate client secrets
      Import M2M Clients from Auth0
    OAuth
    • Identity providers

      • Overview
        Provider setup
      Getting started with the API (Google)
      Add Google One Tap via the SDK
      Email address behavior
      Adding PKCE to an OAuth flow
    Connected AppsBeta
      Setting up Connected Apps
      About Remote MCP Servers
    • Resources

      • Integrate with AI agents
        Integrate with MCP servers
        Integrate with CLI Apps
    Passcodes
      Getting started with the API
      Getting started with the SDK
    • Toll fraud

      • What is SMS toll fraud?
        How you can prevent toll fraud
      Unsupported countries
    Passkeys & WebAuthn
    • Passkeys

      • Passkeys overview
        Set up Passkeys with the frontend SDK
    • WebAuthn

      • Getting started with the API
        Getting started with the SDK
    Passwords
      Getting started with the API
      Getting started with the SDK
      Password strength policy
    • Email verification

      • Overview
        Email verification before password creation
        Email verification after password creation
    Sessions
      How to use sessions
      Backend integrations
      Frontend integrations
      Custom claims
      Custom claim templates
      Session tokens vs JWTs
      How to use Stytch JWTs
    TOTP
      Getting started with the API
      Getting started with the SDK
    Web3
      Getting started with the API
      Getting started with the SDK

    Authorization

    Implement RBAC with metadata

    3rd Party Integrations

    Planetscale
    Supabase
    Feathery
    Unit

    Testing

    E2E testing
    Sandbox values
Get support on SlackVisit our developer forum

Contact us

Consumer Authentication

/

Guides

/

About Stytch

/

Migrations

/

Additional migration considerations

Migrating other application logic

Deploying a new authentication service is not always limited to just changing login and signup logic. If your backend reads session and user data or listens to auth related events, you may need to refactor this logic to point to Stytch’s APIs.

Ingesting events and managing visibility

If your legacy auth provider requires you to set up log streams or webhooks for event visibility, here are a few examples of how to move that logic to Stytch.

With Stytch, there are two ways to gain access to authentication related logs.

Option 1: Log calls and responses made to Stytch from within your own application:

Frontend SDK example, using email magic links with JS:

const onSubmit: FormEventHandler = async (e) => {
    if (isValidEmail(email)) {
      const resp = await stytchClient.magicLinks.email.send(email);

      // Send the response of the call to your logging tool
      // This includes the user info and response code

      if (resp.status === 200) {
        Bugsnag.notify(resp);
        setEMLSent(STATUS.SENT);
      } else {
        Bugsnag.notify(e);
        setEMLSent(STATUS.ERROR);
      }
    }
  };

Backend SDK/API example, using python:

@app.route("/login_or_create_user", methods=["POST"])
  def login_or_create_user() -> str:
      resp = stytch_client.magic_links.email.login_or_create(
          email=request.form["email"],
          login_magic_link_url=MAGIC_LINK_URL,
          signup_magic_link_url=MAGIC_LINK_URL,
      )
      # Send the response of the call to your logging tool
      # This includes the user info and response code

      if resp.status_code == 200:
        bugsnag.notify(resp)
      
      if resp.status_code != 200:
          bugsnag.notify(resp)
          print(resp)
          return "something went wrong sending magic link"

      return render_template("emailSent.html")

Option 2: Check out the Event Logs in the Dashboard

Our Dashboard has Event Logs that aggregates and displays logs that are queryable for you to debug your authentication flows.

Option 3: Webhooks coming soon

If you're interested in leveraging webhooks from Stytch to log authentication events, contact us.

Pre-production testing

If you run any automated or pre-production testing that includes authentication, here are a few best practices to move that to Stytch:

  • If you have multiple pre-production environments that need their own user bases, you should create multiple Stytch projects and have each set of test keys map to each environment.
  • Stytch supports sandbox values to use for most primary login factors. Check out our E2E Testing resource for additional information.

Reconciling deduplication

Stytch uses email or phone number as a primary key for identifying users. This means if you are using a combination of the Stytch Email Magic Links product and OAuth Logins then Stytch will automatically deduplicate users with matching email addresses. For example, if you create a user via Email Magic Links using the email address example@stytch.com, and then later login with a Google account which is tied to example@stytch.com, Stytch will treat these as the same user with the same user_id.

For this reason, you may need to merge your users' accounts before migrating to Stytch. If your script attempts to manually create two users in Stytch with the same email address, you will receive a duplicate_email error.

Linking Stytch users back to your db

You should continue to maintain your own internal user table in your application, and link Stytch’s user_id in as a column in your table. You can also add your internal reference of the user as a trusted_metadata field on the Stytch user.

Migrating over additional user data

Our trusted_metadata supports nested JSON and can be used to migrate and store any additional user data.

We recommend to keep this data limited to information that is required in the context of authentication, for example: user role or other claims

Keeping identifiers consistent: If you have analytics or other internal processes that key off of your internal user ID reference, and would like these IDs to stay consistent, we recommend to add your internal user ID as trusted_metadata. Your backend should then default to reading ID from this value, but fall back to the Stytch user_id if it does not exist. Stytch does not currently support seeding user guids.

Email/phone verification status

Stytch manages the email and phone verification status of users. When a user is created in Stytch, it will have a email.verified or phone.verified value of false until the user completes their first login that verifies ownership of that account (for example an email OTP, SMS OTP flow or OAuth login).

See more information in our guides here.

If you have users who already have verified emails or phone numbers and would like to migrate those users with a verified status, contact us.

You will not be able to add additional factors onto new or migrated users unless their primary authentication factor is verified, to prevent account takeover attacks.

We strongly recommend to only migrate both factors for users who have verified ownership over both of these factors, in order to prevent account takeovers.

Password strength requirement changes

See our Docs for password strength configuration here.

The default password strength policy is zxcvbn, but Stytch offers configurability of this policy via the Dashboard.

For those migrating users with passwords, our recommendations are to:

  1. Turn off breach and strength checks on authentication, so that migrated users aren’t subject to any changes in password strength requirements unless they ever voluntarily reset their password. This can be done in the Stytch Dashboard.
  2. You may configure your strength requirements to match your current requirements, but we advise for all customers to adopt our strongest policy, zxcvbn, in order to improve your security posture. You may have this new policy only apply to new users and existing users who are resetting their password via step 1.

Ingesting events and managing visibility

Option 1: Log calls and responses made to Stytch from within your own application:

Option 2: Check out the Event Logs in the Dashboard

Option 3: Webhooks coming soon

Pre-production testing

Reconciling deduplication

Linking Stytch users back to your db

Migrating over additional user data

Email/phone verification status

Password strength requirement changes