9 October 2025 (v2.144)

ReachFive v2.144 brings several new features:

As always, we fixed a few items for you.

Mobile SDK updates

We also have several updates to both our Android and iOS SDKs. This includes some breaking changes, so please review the Mobile SDK updates section carefully.

You can jump directly to the SDK repositories and documentation with the links below.

SDK repository Version Docs

Android SDK

10.0.0

Android SDK

iOS SDK

10.0.0

iOS SDK


Pass state in forgot password endpoint

You can now include an optional state parameter when calling the POST /identity/v1/forgot-password endpoint. This enhancement lets frontends access and use the state parameter before calling POST /identity/v1/update-password, for example to warn users if the verification code has expired.

The value of state is returned unchanged in the password reset URL sent to the user (by email or SMS). This allows you to pass contextual information, such as the code expiration time, session identifiers, or any other client-specific metadata, between the reset request and the password reset page.

The state value must be URL-encoded to ensure it is safely included in the password reset link.

For example:

POST /identity/v1/forgot-password
{
  "email": "user@example.com",
  "state": "expires_at=1761936000" (1)
}
1 In this case, state specifies that the verification code expires on October 10, 2025 (in Unix timestamp format, seconds).

The resulting password reset link includes the encoded state value:

https://YOUR_URL/password-reset?verification_code=558885362&email=user@example.com&state=expires_at%3D1761936000


New scope field for login user events

Login-related user events (such as SuccessfulLogin) now include a new field:

  • scope (array of strings) — The list of OAuth/OpenID scopes granted to the user during this login or token refresh.

This addition allows auditing and debugging of the permissions granted at the time of authentication.

For more details, see User Events.

Example
{
  "event": "login",
  "user_id": "123456",
  "client_id": "mobile-app",
  "auth_type": "password",
  "scope": ["openid", "profile", "email"], (1)
  "time": "2025-10-07T12:34:56Z"
}
1 In this case, scope is openid, profile, and email.


LinkedIn Connect updates

We have updated ReachFive to support the latest LinkedIn authentication API. The previous API used for LinkedIn Connect was deprecated by LinkedIn on August 1, 2023.

To ensure a smooth transition and avoid breaking changes, ReachFive now supports both the old and new LinkedIn APIs. The correct API is automatically selected based on the configured scopes.

Clients using LinkedIn Connect should create a new LinkedIn app and update their configuration to include the new scopes.

2144 linkedin
API version Required scopes

New API

  • openid

  • email

  • profile

Old API (deprecated)

  • r_liteprofile

  • r_emailaddress

  • w_member_social

The old LinkedIn API has been deprecated and may be removed by LinkedIn in the future. We recommend migrating to the new API as soon as possible to ensure continued compatibility.

For more details, see LinkedIn Connect.


Failure indicator for duplicate import jobs

Import jobs that are stopped due to duplicate user entries in the uploaded data now clearly indicate a failure. Previously, a job containing duplicates would stop without processing any rows but still report successful. This improvement ensures you can immediately understand and act on duplicate-related import issues.

With this update:

  • The job status is marked as FAILURE when duplicates are detected.

  • A clear error message is logged and visible in the ReachFive Console, explaining that the job was interrupted due to duplicate entries.


Mobile SDK updates

We have released new versions of our mobile SDKs with several improvements and breaking changes.


Breaking change : Prevent unverified users logging in at signup

The mobile SDKs (iOS and Android) now support the "Forbid login on signup with unverified email" feature introduced in ReachFive 2.143. When this feature is enabled, the signup flow may not return an AuthToken if the user’s email or phone number is unverified during signup.

This introduces a breaking change, as the signup callbacks now return a flow object rather than always returning a token.

  • Android SDK

  • iOS SDK

signup now returns a SignupResponse which can be:

  • AchievedLogin(authToken): signup completed and the user is immediately logged in.

  • AwaitingIdentifierVerification: signup pending verification (email or phone). In this case, no AuthToken is provided.

signup now returns a SignupFlow with the same possible outcomes:

  • .AchievedLogin(authToken: AuthToken): signup completed and the user is immediately logged in.

  • .AwaitingIdentifierVerification: signup pending verification. In this case, no AuthToken is provided.

Impact on Integrators:

  • Your application logic must handle both possible outcomes of the signup flow (AchievedLogin vs AwaitingIdentifierVerification) to prevent runtime issues.

  • Ensure that your UI and backend processes can gracefully handle cases where the user must verify their identifier before receiving an authentication token.

  • This may require updates to existing signup handling logic, token storage, and error handling in both mobile SDKs.

Trust device during MFA enrollment

The mobile SDKs (Android only at this time) now allows users to trust their device when enrolling a second factor for multi-factor authentication (MFA), providing greater flexibility during the setup process. This feature extends the existing trust device capability, previously available only during login (Multi-factor Authentication), to the MFA enrollment process.

To enable this, set the trustDevice parameter to true (default is false) in the following SDK methods:

  • Android

  • iOS

Behavior:

  • For verified identifiers (email or phone number), setting trustDevice to true during the startMfaEmailRegistration or startMfaPhoneNumberRegistration methods will trust the device and return the __Host-trusted-device-id cookie.

  • For unverified identifiers, the trustDevice parameter is only taken into account during the verifyMfaEmailRegistration or verifyMfaPhoneNumberRegistration methods, after the verification code is submitted.

  • When trustDevice is set to true, the device is trusted in the backend, and the __Host-trusted-device-id cookie is deposited, consistent with the login flow behavior.

Impact on Integrators:

trustDevice is an optional parameter (default is false), so existing integrations will continue to function without modification.

  • Update your mobile SDK integration to include the trustDevice parameter where applicable, ensuring proper handling based on the identifier’s verification status.

  • Refer to the table in the ReachFive 2.132 Release Notes for a summary of when the trustDevice parameter is applicable and when the cookie is returned:

Customizable MFA email and SMS templates for step-up and enrollment

The mobile SDKs (iOS and Android) now support customization of email and SMS templates for both step-up MFA and MFA enrollment processes, allowing you to tailor messaging based on specific user journeys.

This is achieved by introducing the action parameter in the following SDK methods:

  • Android

  • iOS

Behavior:

  • The action parameter allows you to specify the journey context, enabling the use of customized email or SMS templates configured in the ReachFive Console.

  • This feature enhances the flexibility of MFA workflows by aligning notification content with specific user interactions or application requirements.

Impact on Integrators:

action is an optional parameter, so existing integrations will continue to function without modification.

  • Update your mobile SDK integration to include the action parameter in the listed methods to leverage customized email and SMS templates.

  • Ensure that corresponding templates are configured in the ReachFive Console to match the specified action values for seamless integration.

Trace origin for password reset requests

The mobile SDKs (iOS and Android) now support tracing the origin of password reset requests, allowing you to provide context for where the request originated. This is achieved by introducing the origin parameter in the following SDK methods:

  • Android

  • iOS

Behavior:

  • The origin parameter is passed to the /identity/v1/forgot-password endpoint, enabling tracking of the request’s source (e.g., app, website, or specific feature).

  • This feature enhances auditability and allows for better monitoring of password reset activities.

Impact on Integrators:

origin is an optional parameter, so existing integrations will continue to function without modification.

  • Update your mobile SDK integration to include the origin parameter in the requestPasswordReset method to provide context for password reset requests.

  • Ensure the origin value is meaningful and aligns with your application’s tracking requirements.

Fixes

Item Fixed

ReachFive Console

Longer MFA Credentials on a user profile weren’t displayed correctly.

✓