Migrating other application logic

Deploying a new authentication service is not always limited to just changing login and signup logic. If your backend logs auth-related events or has a pre-existing RBAC implementation, 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 multiple ways to gain access to authentication-related logs.

Option 1: Use Webhooks

Customers on the Pro tier and above can enroll in webhooks through the Stytch Dashboard by specifying URL(s) at which you wish to receive the webhook POST requests and the type of events you wish to receive.

Check out our webhooks guide to learn how to keep your internal database records in sync with any changes that occur in Stytch's B2B SaaS API.

// Example organization create via dashboard (dashboard.organization.create)
    "project_id": "project-live-123-...",
    "event_id": "event-live-123-...",
    "action": "CREATE",
    "object_type": "organization",
    "source": "DASHBOARD",
    "id": "organization-live-123-...",
    "timestamp": "2024-03-07T18:49:32.760777783Z",
    "organization": { ... }

// Example update member event via SCIM (scim.member.update)
    "project_id": "project-live-123-...",
    "event_id": "event-live-456-...",
    "action": "UPDATE",
    "object_type": "member",
    "source": "SCIM",
    "id": "member-live-123-...",
    "timestamp": "2024-03-07T18:49:32.760777783Z",
    "member": { ... }

// Example delete SAML connection event via JS SDK or API (direct.saml_connection.delete)
    "project_id": "project-live-123-...",
    "event_id": "event-live-789-...",
    "action": "DELETE",
    "object_type": "saml_connection",
    "source": "DIRECT",
    "timestamp": "2024-03-07T18:49:32.760777783Z",
    "id": "saml-connection-live-123-..."

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

Frontend SDK example, using Email Magic Links with JavaScript:

const onSubmit: FormEventHandler = async (e) => {
    if (isValidEmail(email)) {
      const resp = await stytchB2BClient.magicLinks.email.send({
          email_address: 'sandbox@stytch.com',
          organization_id: 'organization-test-07971b06-ac8b-4cdb-9c15-63b17e653931',

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

      if (resp.status === 200) {
      } else {

Backend SDK/API example, using Python:

@app.route("/login_user", methods=["POST"])
  def login_user() -> str:
      resp = stytch_b2b_client.magic_links.email.send(
      # Send the response of the call to your logging tool
      # This includes the user info and response code

      if resp.status_code == 200:
      if resp.status_code != 200:
          return "something went wrong sending magic link"

      return render_template("emailSent.html")

Option 3: 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.

Migrating SSO connections

There are two ways to migrate over SAML or OIDC connections from your existing auth system to Stytch:

  1. Proxy connections (only available if IdPs are configured with redirect URLs to your domain). Forward requests from the URLs you already have set up to the Stytch URLs we provide.
  2. Create new SSO Connection objects (SAML or OIDC) for each Organization. You will need to change all SSO settings in your customer's IDPs to point to Stytch's URLs. Follow these SSO guides for more information on how to set up SSO.

Migrating roles and permissions

If your application has an authorization system that resembles role-based access control (RBAC), you can transfer roles and permissions over to Stytch's RBAC framework.

Refer to our RBAC guides for more information and instructions on how to create roles, resources, and permissions, and how to programmatically assign roles to Members.

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.
  • We recommend creating test users and organizations that can be used for any authentication testing and QA flows.

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 keeping this data limited to information that is required in the context of authentication; for example, internal identifiers, profile information, and 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 adding your internal user ID as trusted_metadata. Your backend should then default to reading ID from this value, but fall back to the Stytch member_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 Member is created in Stytch, it will have an email.verified or phone.verified value of false until the user completes their first login that verifies ownership of that account (e.g., an Email Magic Link or OAuth login).

Password strength requirement changes

See our Docs for password strength configuration here.

The default password strength policy is zxcvbn, but Stytch offers configuration 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 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.