Skip to main content

Overview

The registration process is an 8-step flow that collects required KYC (Know Your Customer) information from new users and establishes formal consent records. Each step must be completed in order, with the onboardingId passed between steps to maintain session continuity. Steps 1-2: Email and phone verification with onboardingId generation. Step 3: KYC identity verification via Veriff using onboardingId (no authentication required). Steps 4-5: Personal details and consent record creation using onboardingId (consent required for regulatory compliance - GDPR, CCPA, E-Sign Act). Steps 6-7: Address collection that finalizes registration and returns userId and accessToken. Step 8: Link consent set to userId to complete the audit trail.
All registration endpoints require the x-client-key header. For US environment routing, include x-us-env: true header or region=us query parameter.
Consent Must Be Created Before Address Submission: Step 5 creates the formal consent record required for regulatory compliance. The address endpoints (Steps 6-7) finalize registration and return the userId, which is then used to link the consent (Step 8). Do not skip consent creation for production deployments handling user data under GDPR, CCPA, or E-Sign Act requirements. See Consent Management for details.

Registration Flow Diagram

Complete Flow Overview

Step 1: Email Verification (Send)

Initiate registration by sending a verification code to the user’s email address.

Endpoint

API Reference: POST /v1/auth/register/email/send

Request

Response

Store the contactVerificationId securely. This ID is required for the email verification step and phone verification step.

Field Descriptions

Common Errors

Resolution: User should login instead, or use password recovery
Resolution: Validate email format before submission

Step 2: Email Verification (Verify)

Verify the code received via email and create the user onboarding session.

Endpoint

API Reference: POST /v1/auth/register/email/verify

Request

Response

The onboardingId returned here must be passed to all subsequent registration steps. Store it securely in your session.

Field Descriptions

Best Practice: After registration completes, use the Consent Management API to create a formal consent record linking the user to their consent choices. This provides an immutable audit trail for regulatory compliance (GDPR, CCPA, E-Sign Act) and allows users to review or revoke their consent later.

Password Requirements

While specific requirements may vary, follow these best practices:
  • Minimum 8 characters
  • Include uppercase and lowercase letters
  • Include numbers and special characters
  • Avoid common passwords

Common Errors

Resolution: Request a new code via Step 1 and try again
Resolution: Codes typically expire after 10-15 minutes. Request a new code via Step 1
Resolution: Restart from Step 1 to get a new verification ID

Step 3: Phone Verification (Send)

Send SMS verification code to the user’s phone number.

Endpoint

API Reference: POST /v1/auth/register/phone/send

Request

Response

Field Descriptions

Phone number should be provided without the country code, spaces, or special characters. The country code is sent separately in phoneCountryCode.

Common Errors

Resolution: Ensure phone number is valid for the specified country code and contains only digits
Resolution: User may already have an account with this number

Step 4: Phone Verification (Verify)

Verify the SMS code and link the phone number to the user’s onboarding session.

Endpoint

API Reference: POST /v1/auth/register/phone/verify

Request

Response

Field Descriptions

Common Errors

Resolution: Request a new code via Step 3 and try again
Resolution: Ensure phone number and country code exactly match Step 3

Step 5: KYC Verification (Veriff)

Generate a verification session URL for identity verification. This step initiates the KYC process where users upload their government ID and complete biometric verification.
No Authentication Required: This endpoint uses onboardingId for validation and does not require a bearer token. The user doesn’t have an access token yet at this stage of registration.

Endpoint

API Reference: POST /v1/auth/register/verification

Request

Response

Field Descriptions

What Happens Next

After receiving the sessionUrl:
  1. Redirect the user to the Veriff session URL
  2. User completes verification by:
    • Uploading a government-issued ID (passport, driver’s license, etc.)
    • Taking a selfie for biometric matching
    • Following on-screen instructions
  3. Verification processing (typically 5-30 minutes)
  4. User returns to your application
  5. Poll for status using GET /v1/auth/register?onboardingId={id} to check verification state

Verification States

The user’s verificationState will be updated to:
  • PENDING: Verification submitted and under review
  • VERIFIED: Verification approved (ready to proceed)
  • REJECTED: Verification rejected (can retry later)

Polling for Completion

Implement polling to detect when verification completes:

Common Errors

Resolution: Verify the onboardingId from Step 2 is correct and hasn’t expired
Resolution: Verification provider may be temporarily unavailable. Retry after a brief delay
User Experience Tip: Consider opening the Veriff session in a modal or in-app browser rather than a full redirect. This provides a better user experience and makes it easier to detect when the user returns.

Step 6: Personal Details

Collect the user’s personal information required for KYC compliance.

Endpoint

API Reference: POST /v1/auth/register/personal-details

Request

Request (US Users)

For users with countryOfResidence = "US", SSN is required:

Response

Field Descriptions

US Users: The ssn field is mandatory when countryOfResidence = "US". Requests will fail validation without it.

Age Validation

Users must meet minimum age requirements (typically 18+). The API will validate the dateOfBirth against this requirement.

Common Errors

Resolution: Verify date of birth is correct. Users under minimum age cannot register
Resolution: Include ssn field when countryOfResidence = "US"

Step 7: Physical Address

Collect the user’s residential address information.

Endpoint

API Reference: POST /v1/auth/register/address

Request (Non-US Users)

Request (US Users)

For US users, include the usState field:

Response (Registration Complete)

When isSameMailingAddress = true OR countryOfResidence != "US":
Registration Complete: When accessToken is returned, registration is complete. Store the token for authenticated API calls.

Response (Mailing Address Required)

When isSameMailingAddress = false AND countryOfResidence = "US":
If accessToken is null, proceed to Step 8 to collect mailing address (US users only).

Field Descriptions

US Users: The usState field is mandatory when countryOfResidence = "US". Use two-letter state abbreviations (e.g., “CA”, “NY”, “TX”).

Common Errors

Resolution: Include usState field when countryOfResidence = "US"
Resolution: Ensure ZIP code matches the expected format for the country

Step 8: Mailing Address (Optional - US Only)

For US users who have a different mailing address than their physical address, collect the mailing address information.
This step is only required when:
  • countryOfResidence = "US", AND
  • isSameMailingAddress = false in Step 7

Endpoint

API Reference: POST /v1/auth/register/mailing-address

Request

Response

Registration Complete: The accessToken returned here completes the registration process. Store it for authenticated API calls.

Field Descriptions

After core registration completes (Steps 1-8), create a formal consent record for regulatory compliance. This step is essential for production deployments handling user data under GDPR, CCPA, or E-Sign Act.
Why This Step Matters: Step 9 creates a formal, immutable audit trail required for regulatory compliance. This provides:
  • Legal proof of consent with timestamps
  • IP address and user agent tracking
  • Complete consent change history
  • Region-specific policy enforcement (US vs Global)
  • Revocation tracking for “right to be forgotten” requests
E-Sign Act Legal Requirement (US Users): For US users, the E-Sign Act legally requires that you present the E-Sign Act disclosure document to users and provide an opportunity to review it before they can consent to eSignAct. This is not optional - it’s a federal legal requirement.Your client application must:
  • Display the full E-Sign Act disclosure document
  • Allow users to read and review it before proceeding
  • Obtain affirmative consent after presentation
Simply showing a checkbox labeled “I agree to E-Sign Act” without providing access to the disclosure document does not meet legal requirements and could invalidate the consent.Best Practice for Other Consents: While not legally mandated in the same way, it’s also good practice to provide access to Terms of Service, Privacy Policy, and Marketing Communications policies before collecting those consents.

Workflow

The consent flow requires two API calls:
  1. Create onboarding consent - Create consent set using the onboardingId from registration
  2. Link user to consent - Associate the permanent userId with the consent set
API Reference: POST /v2/consent/onboarding

Request

Response

Store the consentSetId returned from this call. You’ll need it for the linking step.
API Reference: PATCH /v2/consent/onboarding/{consentSetId}

Request

Response

Registration Complete with Audit Trail: Once the user is linked to the consent set, your registration flow is complete with full regulatory compliance. The consent record includes immutable audit trails for all future changes.

Policy Selection

Choose the correct policy based on the user’s country of residence:
E-Sign Act Disclosure for US Users: The eSignAct consent is required for US users under the federal Electronic Signatures in Global and National Commerce Act. Your client application must present the E-Sign Act disclosure document to users and provide an opportunity to review it before they can consent. The disclosure typically explains:
  • What it means to conduct business electronically
  • How to withdraw consent
  • How to obtain paper copies of documents
  • Hardware and software requirements
  • How to contact the company
This is a legal requirement - users cannot legally consent to something they haven’t been given the opportunity to read.
Mapping Registration to Consent: The consent choices from Step 2 (allowMarketing, allowSms) should be used to set the status values in Step 9:
  • allowMarketing: truemarketingNotifications: "granted", emailNotifications: "granted"
  • allowMarketing: falsemarketingNotifications: "denied", emailNotifications: "denied"
  • allowSms: truesmsNotifications: "granted"
  • allowSms: falsesmsNotifications: "denied"
  • termsAndPrivacy should always be "granted" (required to register)
  • eSignAct (US only) should always be "granted" (required for US users)

Common Errors

Resolution: Ensure policy matches user’s country (us for US, global for others)
Resolution: Verify the onboardingId from Step 2 and ensure it hasn’t been used before
Resolution: Cannot link the same consent set to multiple users. Create a new consent set for each user.
Once consent is established, you can: See the complete Consent Management Guide for details on audit trails, revocation, and compliance best practices.

Complete Registration Example

Here’s a complete end-to-end example implementing all registration steps:

Troubleshooting

Session Expiration

Onboarding sessions may expire if too much time passes between steps. If you receive an “invalid onboarding ID” error:
  1. Check if the session has expired (typically 30-60 minutes)
  2. Restart the registration flow from Step 1
  3. Complete all steps within the session timeout window

Verification Code Issues

If users report not receiving codes:
  1. Email: Check spam/junk folders, verify email address is correct
  2. SMS: Verify phone number format, ensure number can receive SMS, check for carrier blocks

Data Validation Failures

Common validation errors and solutions:
  • Invalid email format: Ensure proper email validation on client side
  • Weak password: Implement password strength checker matching server requirements
  • Invalid date format: Use YYYY-MM-DD format consistently
  • Invalid country code: Use ISO 3166-1 alpha-2 codes (2-letter codes)
  • Phone number format: Remove spaces, dashes, and formatting characters

Best Practices

Client-Side Validation

Validate all fields on the client side before API submission to reduce errors and improve UX

Progress Tracking

Show users clear progress indicators through the 8-step flow so they know where they are

Error Messages

Provide clear, actionable error messages. Don’t just show API errors—explain what the user should do

Session Management

Store onboardingId securely and implement timeout warnings to prevent session expiration

Code Resend

Implement “resend code” functionality for both email and phone verification with rate limiting

Field Persistence

Save form progress locally so users don’t lose data if they navigate away or refresh

Next Steps

After successful registration (including Step 9 consent):
  1. ✅ Store Access Token: Securely store the returned accessToken for authenticated API calls (6-hour validity)
  2. ✅ Consent Established: Your consent record with audit trail is now active. Users can manage consent via their profile
  3. Identity Verification: Direct users to complete identity verification via GET /v1/user/verification
  4. Profile Management: Allow users to view and update their profile via Profile Management
Production Checklist: Ensure Step 9 (Consent Management) is implemented before deploying to production. Missing consent records can result in regulatory compliance issues.

Consent Management

Learn about consent audit trails, revocation, and compliance

Authentication Guide

Learn about login flows and session management

Profile Management

Managing user information after registration