Our StoryBlogPodcastAdoption Report
Updates
Activate Account
Back to All

October 2025

October 2nd, 2025

To better facilitate the management of a large number of customer and end-provider configurations, the Trinsic platform has migrated from "Apps" to "Verification Profiles".

Verification Profiles & Environments

  1. Apps have been renamed to Verification Profiles.
  2. Your organization now has two environments -- Live and Test -- which can be switched between in the Dashboard. Verification Profiles reside within environments.
  3. [BREAKING] Auth Tokens are now organization-level and are tied to an Environment rather than a specific App / Verification Profile.
    1. App-specific Auth Tokens are now called "Legacy Tokens" and will stop functioning after 90 days.
  4. [BREAKING] Some API endpoints now require a verificationProfileId parameter.
    1. Previously, these API endpoints were called with Auth Tokens tied to a specific App / Verification Profile ID. These Auth Tokens are now Legacy.
    2. Existing integrations will continue to function for 90 days.
  5. Providers must now be explicitly "added" to Verification Profiles, during or after creation.
    1. If a Provider has no required approval or registration process, it will be immediately available for use.
    2. If a Provider requires approval and/or a registration process, the Provider will be added to the Verification Profile in a disabled, unapproved state.
      1. Once the necessary approvals / registrations are performed by Trinsic, the Provider will appear as "Approved" for your Verification Profile.
    3. Once added to a Verification Profile, a Provider can be enabled or disabled indepenently.
  6. Redirect URLs are now tied to Environments as opposed to individual Apps / Verification Profiles.
  7. User management has been improved
    1. As before, users within an organization may be a "Member" or an "Admin."
      1. Admins may access all environments and modify the roles of other users within the organization.
      2. Members may only access environments they are given access to, and cannot modify other users' roles.
    2. Access to Apps / Verification Profiles is now determined by the environments a user has access to
      1. By default, a user with the role of "Member" may only access the Test environment within an organization.

Other breaking changes

  1. The Advanced API has been renamed; it is now the Direct API.
    1. No functionality has changed, but an SDK update is required in order to hit the correct new routes for these API endpoints.
    2. Existing integrations will continue to function for 90 days.
  2. Our Web UI SDK has been updated to version 3.0.0
    1. This SDK has been restructured to provide a higher level of control over the user experience and popup management, if needed for your integration.
    2. Complexities around certain browser security restrictions (e.g. Cross-Origin-Opener-Policy), which can cause issues with cross-window communication as required by this SDK, are addressed by this update.
  3. For the endpoints Submit Native Challenge Response and Refresh Step Content, the acceptanceSessionId parameter has been renamed to sessionId.

Other changes

  1. Trinsic's internal "Test" providers (e.g., "Test - Redirect") have been renamed to "Mock" providers.
    1. This is a cosmetic change only

Upcoming Changes

  1. The base domain name for Trinsic's user-facing endpoints will soon change
    1. User redirects (including launchUrl), as well as Trinsic's Widget and Hosted UIs, will be served from verify.trinsic.id.
    2. The domain name of the Trinsic API (api.trinsic.id) will remain the same.
    3. No changes to your integration are necessary to support this change.


Migration Guide

ℹ️

Deprecation Timeline

No immediate changes are necessary to retain existing functionality with your Trinsic integration.

All changes described in this document are fully backwards-compatible for 90 days from the posting of this notice.

Auth Tokens & verificationProfileId Parameter

Relevant to: all integrations

Existing Auth Tokens, which are scoped to specific Verification Profiles (previously "Apps"), are now considered Legacy Tokens. These Tokens will cease functioning 90 days after the posting of this document.

Auth Tokens are now scoped to your organization and environment, as opposed to individual Verification Profiles within an environment. A token for the test environment may create Sessions for any Verification Profile in that environment.

Because Organization Tokens are not tied to specific Verification Profiles, a newverificationProfileId parameter is required when calling the following endpoints with an Organization Token:


Changes Required

  1. Replace your Legacy Tokens with Organization Tokens
    1. Your Organization Tokens can be found on the Developer page of the Trinsic Dashboard.
    2. Store the new Organization Token for each environment in your secret storage system.
  2. Update your Backend SDK
    1. Organization Tokens require the newest version of Trinsic's backend SDKs
    2. If you are not using a backend SDK, you will need to update your implementation against our API reference for the affected endpoints.
      1. Specifically, you must include the verificationProfileId parameter in either the route or request body for each endpoint.
  3. Specify verificationProfileId in affected API calls
    1. Since tokens are no longer tied to specific Verification Profiles, you must specify the verificationProfileId you wish to use in the above-listed API calls.


Renaming of Create Advanced Provider Session Endpoint

Relevant to: integrations which call this endpoint

This endpoint has been renamed to Create Direct Provider Session to better reflect its nature. No other changes have been made besides the addition of the verificationProfileId parameter as part of the auth token changes.


Changes Required

  1. Update your Backend SDK
    1. The new endpoint names and paths will automatically be included with the latest version of our SDK.
    2. If you are not using a Trinsic SDK, you will need to update your integration to call the new route of the endpoint. See reference.


Web UI SDK v3.0.0

Relevant to: integrations which use the Trinsic Web UI SDK to launch popups via launchPopup

Our Web UI SDK has been updated to v3.0.0. This introduces a compile-time breaking change with the removal of the launchPopup method. Additionally, we have reworked the cross-window communication mechanisms and included a related helper function.


⚠️ Note on iFrames

If you are launching a Trinsic popup from within an iFrame, there are additional complexities to be aware of due to various browser security mechanisms.

This SDK update includes improved support for iFrames, but brings with it additional requirements. Please read the Web UI SDK Documentation to better understand the requirements of launching from an iFrame.


resultsAccessKey No Longer Returned

Previously, this library would return a resultsAccessKey to your frontend after the popup session resolved. This has been removed. Instead, use the resultsAccessKey provided to your backend during Session creation.

This change has been implemented to ensure that the resultsAccessKey for a Session is saved securely in your backend context.


Redirect Handling

When calling launchPopup with Create Hosted Provider Session or Create Direct Provider Session], you previously had to implement custom cross-window messaging to signal completion of a Session (or implement polling). Our SDK now provides this out of the box.

As before, create a Hosted Provider Session with a redirectUrl pointing to a page you control. When the user lands on this page, pull out the sessionId from the query parameters and signal completion to the window which opened the popup:

import { signalRedirectFromPopup } from "@trinsic/web-ui";

const urlParams = new URLSearchParams(window.location.search);
const sessionId = urlParams.get("sessionId");

// Signal to the window which opened this popup that the Session is done
signalRedirectFromPopup(
  {
    sessionId: sessionId,
    closeWindowAfterSignal: true
  }
);

launchPopup() -> createPopupAndWaitForResults()

For the simplest migration, use the included helper function createPopupAndWaitForResults(), which has a similar API surface to the previous launchPopup method:

import { createPopupAndWaitForResults } from "@trinsic/web-ui";

// Create a popup, initialize it with a launch URL, and wait for it to signal completion
const result = await createPopupAndWaitForResults({
  // A callback function which should call your backend to create a Trinsic Session,
  // and return the Launch URL.
  //
  // This pattern is necessary due to browser restrictions around opening a popup too late
  // after a user gesture (e.g. button click).
  sessionCreationFunction: async () => {
    // Hit your backend to create a Trinsic Session and return its launch URL
    return await createTrinsicSessionLaunchUrl();
  },
});

// Notify your backend of Session completion
const sessionId = result.sessionId;
await notifyBackend(sessionId);

// Previous implementation
import { launchPopup } from "@trinsic/web-ui";

// Call `launchPopup()`, passing a callback to asynchronously create a Session URL
// `launchPopup()` resolves when it receives a completion signal from the popup, or on error
const result = await launchPopup(async () => {
  // Hit backend to create a Trinsic Session and return its launch URL
	return await createTrinsicSessionLaunchUrl();
});

// Notify your backend of Session completion
const sessionId = result.sessionId;
await notifyBackend(sessionId);

Optional: createPopup() API

For more direct control over the popup management process, including the ability to respond to the possible closure of the popup with custom logic or close the popup at will, use the new createPopup() API.

Please see the Web UI SDK Documentation for a usage example.