Pre-Register & Activate

🚧
Deprecation Notice
The content on this page has been deprecated and is no longer valid. We have made significant improvements and updates to provide you with the most accurate and up-to-date information.
To access the latest content, please visit: Pre-register.

The pre-register journey enables an application to invite a user to activate their account when self-registration isn't a supported method of registration.

The typical pre-register journey includes the following steps:

Step	Description
Pre-Register	The user account is created by your application team, and pre-populated with a limited set of known data (like email address, first name, and last name, for example). Upon successful pre-registration, the use is sent an email or SMS with the information needed to activate their account.
Activate	After the account is successfully pre-registered, the user will receive an email or SMS with instructions to activate their account. Clicking or tapping the link included in the message will take the user to the activation screen. The activation screen includes additional information the user needs to provide to complete their account registration (like address and password, for example), and prompts the user to view consent-related information like terms and conditions and privacy notices.

Step

Description

Pre-Register

The user account is created by your application team, and pre-populated with a limited set of known data (like email address, first name, and last name, for example). Upon successful pre-registration, the use is sent an email or SMS with the information needed to activate their account.

Activate

After the account is successfully pre-registered, the user will receive an email or SMS with instructions to activate their account. Clicking or tapping the link included in the message will take the user to the activation screen. The activation screen includes additional information the user needs to provide to complete their account registration (like address and password, for example), and prompts the user to view consent-related information like terms and conditions and privacy notices.

Assumptions

Your application does not allow users to self-register and requires them to be pre-registered and invited to activate their new account.

Integration

Here is an example of how to configure the pre-register API call. The specific fields needed will depend on your application requirements.

curl --location --request POST 'https://id.eu.nextreason.com/idp/v1/account/pre-register' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic REDACTED'
--data-raw '{
    "profile_fields": {
        "firstName": "John",
        "lastName": "Smith",
        "emailAddress": "[email protected]",
        "resourceAccessB2b": "true"
    },
    "client_id": "c8462jyq9dnupu2q4j7sfjzvn6c87j92",
    "locale": "en-US",
    "auth_type": "email",
    "grant_type": "password",
    "redirect_uri": "https://localhost.com"
}'

Base Domain

In this example above, the base domain is https://id.eu.nextreason.com/.

Endpoint

The endpoint to use for this is /pre-register.

Parameters

Below are the required and optional parameters for the /pre-register endpoint. Your specific parameters may vary depending on your configuration; if you're unclear on the parameters to use, please contact your Next Reason integration consultant.

Required Parameters

The following parameters must be included on every /pre-register request.

Parameter	Description
Basic authorization header	Required as part of the header. Note that the basic authorization must only be used when it can be passed in a secure server-to-server manner.
`auth_type`	This is the method that the user will use for sign in, this will either be email or SMS and is dependent on your client ID configuration. When `auth_type` is set to `email`, the rate limiting functionality is implemented, preventing resending verification code requests within a configured time duration.
`client_id`	The ID used to authenticate the API call. This client ID is tied to your specific configurations and rules. Contact your integration consultant if you do not know your client ID.
`grant_type`	In this case the `grant_type` value will be password
`profile_fields`	This is the object of user data (field name and value pair) that will create your user record.
`redirect_uri`	Configures the URL the user is redirected after a successful activation of their account on the hosted screens. Important reminders: This URL must be included in the safelist configuration. Contact your Next Reason integration consultant to add URLs to this list. The `redirect_uri` parameter is only validated against the allowList* and is not used in the email link. The email link will redirect the user to the activation form. Once completed, the user will be redirected back to the configured `app_link` setting. The `/token` call needs to include the `app_link` URL in order to get the token and not the originating `redirect_uri` from the first call.

Optional Parameters

The following parameters are optional.

Parameter	Description
`locale`	Set the language to be displayed in the hosted screen. Since the `locale` parameter is optional, if there is not present it will use whatever default value is set for your configuration See Localization for the list of supported locales and the accepted values.
`resend`	This parameter resends the invite link for both mobile and email, but will ignore whether the user already exists or not. The default value is `false`.

Parameter

Description

locale

Set the language to be displayed in the hosted screen.

Since the locale parameter is optional, if there is not present it will use whatever default value is set for your configuration

See Localization for the list of supported locales and the accepted values.

resend

This parameter resends the invite link for both mobile and email, but will ignore whether the user already exists or not.
The default value is false.

Response

A successful response after user has been created via the /pre-register endpoint will only include the uuid of the user—for example

{ "uuid": "69ed0122-f2d9-4c6e-a636-3670cab4f15f " }