27 March 2025 (v2.132)

ReachFive v2.132 introduces several improvements and needed bug fixes. Alongside this release, we have introduced new methods for the Android SDK . You can also now trust a device when enrolling a second factor for MFA.

In addition to those, it’s now possible to enroll users in MFA through import jobs. We’re also excited to show you our improved console design.

As always, we made some general improvements and fixed a few items for you.


Android SDK updates

We are happy to announce a few updates to our Android SDK . This includes two new methods where you can initiate and complete the email verification process for users through a verification code.

For more, see:


Trust device when enrolling second factor

2132 trust device

Previously, you could only trust your device when logging in with Multi-factor Authentication. With this release, you can now trust your device when registering a second factor for MFA, giving you more flexibility right from the setup process.

To do this, you can set trust_device to true using the following endpoints and methods, allowing you to integrate in a way that suits your ReachFive setup best.

When you need to set trust_device to true or not depends on if the identifier involved is verified or not. As the table below shows, you can trust a device and return the __Host-trusted-device-id cookie for already verified identifiers when starting MFA registration. However, for unverified identifiers, you must complete both the start and verify steps.

Identifier status Step Provide trust_device? Cookie returned?

Verified

Start MFA registration

Verify MFA registration

Not required

Unverified

Start MFA registration

Verify MFA registration

  • API

  • Core SDK


Enroll users in MFA with import

You can now enroll your users for Multi-factor Authentication through an import. This lets you quickly protect users instead of waiting for user interaction, which is helpful for less active profiles on your system.

If the user’s email and/or phone number is unverified, the profile is still imported, but the user is not registered for MFA. A warning is logged in the import logs for your records.

For the successfully enrolled users, the following event types are emitted:

To enroll a user through import, you need to pass enroll_<identifier>_as_mfa_credential set to true on the user profile.

User profile model example
{
  "external_id": "1",
  "email": "foo@gmail.com"
} \n
{
  "email": "bar@gmail.com",
  "name": "Joe",
  "gender": "M",
  "enroll_email_as_mfa_credential": true, (1)
  "enroll_phone_as_mfa_credential": true, (2)
  "custom_fields": {
      "has_loyalty_card": true
  },
...
}
1 Enrolling email for MFA (only registers if the email is verified).
2 Enrolling phone number for MFA (only registers if the phone number is verified).


Improved console design

We are excited to announce that we have improved the design for the ReachFive Console, giving it a much-needed facelift. The design provides a cleaner look and feel and is more responsive and user friendly. This includes the ability to choose light or dark mode (or system) and sleeker navigation design.

Please bear with us as we update screenshots in documentation related to console features.

  • Light preview

  • Dark preview

2132 console light
2132 console dark


General improvements

  • We now return an improved error response for when a user attempts to authenticate through social login and there is a match on an unverified phone_number for the user’s profile.

    Error example
    error.socialAccountPhoneNumberAlreadyInUse (1)
error.socialAccountPhoneNumberUnverified (2)
    1 "The phone number associated with this {0} account is already used by an other account".
    2 "The phone number associated with this {0} account is unverified for the profile ID: {1} ".

  • You can now export MFA credentials in user export jobs.


Fixes

Item Fixed

There was temporarily an issue where some SLO provider signup details were not being included as expected when used with a Pre-event webhook. The provider details are now again returned as expected.

✓

Session cookies were being lost prematurely during the passwordless verification code flow. This was causing some limited issues for users, but it is now resolved.

✓

In some instances, custom fields for a user profile that were imported were subsequently not included in an export as expected.

✓