Skip to main content
POST
Authenticate User

Overview

Authenticate a user with their credentials to obtain an access token. This endpoint is used in two contexts:
  1. OAuth Step 2 (API Mode): When using mode=api in OAuth flow, this step authenticates the user to get an access token needed for Step 3
  2. Direct Login: For applications not using OAuth, this provides immediate access token for API authentication
The access token returned expires in 6 hours and should be used in the Authorization: Bearer header for authenticated API requests.

When to Use

  • Implementing OAuth 2.0 flow in API-mode (Step 2 of 4)
  • Direct user authentication without OAuth
  • Need to verify user credentials and get access token
  • User login for internal applications
This step is NOT needed when using the hosted UI OAuth flow (without mode=api). The hosted UI handles authentication automatically.

Request

Headers

string
required
Your public API client key
boolean
Set to true to route requests to the US backend environmentDefault: false (international environment)

Body Parameters

string
required
User’s email addressFormat: Valid emailExample: user@example.com
string
required
User’s passwordFormat: Password stringExample: SecurePassword123!
string
One-time password code (required only if user has OTP enabled)Call POST /v1/auth/login/otp first to send the OTP code to the user’s phoneLength: 6 digitsExample: 123456

Response

string
required
Access token for API authenticationUse this in Authorization: Bearer header for authenticated endpointsExpiry: 6 hoursExample: US_b6b9168a-bb56-4c6a-9c0d-4650ea74f5f9
string
User’s unique identifierFormat: UUIDExample: b6b9168c-bb56-4c6a-9c0d-4650ea74f5f9
boolean
Indicates if user requires OTP verificationIf true, you must:
  1. Call POST /v1/auth/login/otp to send OTP code
  2. Retry this endpoint with otpCode parameter
Example: false
string
Masked phone number (only returned if isOtpRequired is true)Example: +445*****225
string
User onboarding phase (only returned during onboarding)Possible values:
  • ACCOUNT
  • PHONE_NUMBER
  • PERSONAL_INFORMATION
  • PHYSICAL_ADDRESS
  • MAILING_ADDRESS
Example: null
string
User’s KYC verification statusPossible values:
  • UNVERIFIED - No verification submitted
  • PENDING - Verification in progress
  • VERIFIED - Successfully verified
  • REJECTED - Verification failed
Example: VERIFIED
boolean
Indicates if client has valid permission to access user’s accountIn OAuth context, false means authorization hasn’t been granted yetExample: false

Success Response

Error Responses

Common causes:
  • Incorrect email or password
  • Account doesn’t exist
  • Account is locked or disabled
Solution: Call POST /v1/auth/login/otp first, then retry with otpCode
Common causes:
  • Invalid email format
  • Missing required parameters
  • Invalid parameter types

Code Examples

OTP Flow Example

If the user has OTP enabled, you need to handle a two-step login process:

OAuth Context: Step 2

When using this endpoint as Step 2 in OAuth API-mode flow:
OAuth Step 2

Edge Cases and Important Notes

Token Expiry: Access tokens expire after 6 hours. In OAuth flow, you should exchange them for long-lived tokens in Step 4. For direct login, implement token refresh logic.
Onboarding Phase: If phase is not null, the user hasn’t completed registration. Guide them through the remaining onboarding steps before allowing full access.
Account Security: Implement rate limiting on your client side to prevent brute force attacks. The API has built-in protection, but client-side throttling improves UX.

Failed Login Attempts

After multiple failed login attempts, accounts may be temporarily locked:

Token Storage Security

Always store access tokens securely:
  • Web apps: Use httpOnly cookies or secure sessionStorage
  • Mobile apps: Use secure device storage (Keychain/Keystore)
  • Never: Store in localStorage or expose in URLs

Response Scenarios

Understanding different response scenarios helps you handle all authentication states correctly and build robust integrations.

Response Field Decision Matrix

Use this table to determine what action to take based on the response field values:
For complete flow explanations with examples, see the Authentication Guide.

HTTP 200: Successful Login (No OTP)

User authenticated successfully with no additional steps required. Response:
Client Action:
  1. Store accessToken securely (sessionStorage, secure storage)
  2. Track token issuance time for expiration handling
  3. Use token in Authorization: Bearer header for all API calls
  4. If isLinked: false and long-lived access needed, initiate OAuth flow
cURL Example:

HTTP 200: OTP Required

User has 2FA enabled. Initial authentication succeeded but OTP verification required. Response:
Why accessToken is null: The token won’t be issued until OTP verification completes. This prevents unauthorized access even if credentials are compromised. Client Action:
  1. Call POST /v1/auth/login/otp with userId to send OTP
  2. Display OTP input field to user
  3. Show masked phoneNumber so user knows where to check
  4. Retry POST /v1/auth/login with credentials + otpCode parameter
  5. Handle OTP-specific errors (invalid code, expired code, rate limit)
Flow:
See Send OTP for detailed OTP endpoint documentation.

HTTP 200: User Onboarding Incomplete

User account exists but hasn’t completed registration. Response:
Phase Values & Meanings:
  • ACCOUNT: Basic account creation (email/password set)
  • PHONE_NUMBER: Phone verification required
  • PERSONAL_INFORMATION: Name, DOB, SSN collection
  • PHYSICAL_ADDRESS: Residential address information
  • MAILING_ADDRESS: Mailing address (if different from physical)
Client Action:
  1. Direct user to continue registration at the specified phase
  2. Do NOT attempt API calls - accessToken is null
  3. Guide user through onboarding steps
  4. After completion, phase will be null and accessToken will be provided
API endpoints requiring authentication will fail with 401 until onboarding completes and a valid accessToken is issued.

HTTP 401: Invalid Credentials

Incorrect email/password combination or account doesn’t exist. Response:
Common Causes:
  • Typo in email or password
  • User hasn’t registered yet
  • Password changed but old credentials used
  • Testing with wrong environment credentials
Client Action:
  1. Display generic error message to user (don’t specify which field is wrong)
  2. Implement rate limiting on client side (exponential backoff)
  3. Offer “Forgot Password” option after 2-3 failed attempts
  4. After 5 failed attempts, suggest account recovery
Security Best Practice:

HTTP 403: Account Locked

Account temporarily locked due to security concerns. Response:
Common Causes:
  • Multiple failed login attempts (brute force protection)
  • Suspicious activity detected
  • Manual lock by admin/support
  • Security policy violation
Client Action:
  1. Display error message with support contact information
  2. Do NOT retry immediately - will extend lock duration
  3. Implement exponential backoff (start with 1 hour delay)
  4. Provide link to account recovery/support
Typical Lock Duration: 15-60 minutes (automatic unlock)

HTTP 422: Validation Error

Request parameters failed validation. Response:
Common Validation Errors:
  • email must be a valid email: Invalid email format
  • password is required: Missing password field
  • otpCode must be 6 digits: Invalid OTP code format
Client Action:
  1. Validate input on client side before submission
  2. Display field-specific error messages
  3. Highlight invalid fields in UI
  4. Prevent submission until validation passes
Client-Side Validation Example:

Edge Cases

Multiple Failed OTP Attempts

After 3-5 failed OTP verification attempts, the account may be temporarily locked. Response:
Handling:

Expired OTP Code

OTP codes typically expire after 5-10 minutes. Response:
Handling:

Environment Mismatch

Using production credentials in sandbox or vice versa. Symptoms:
  • 401 errors despite correct credentials
  • User not found errors
  • Token format mismatch errors
Resolution:

Token Already Exists

User attempting to login while already having a valid session. Behavior:
  • New token is issued
  • Previous token remains valid until expiration
  • No error returned
Best Practice:

Network Timeout During Authentication

Request timeout or network interruption. Handling:

Race Condition: Multiple Simultaneous Login Requests

If multiple login requests are made simultaneously (e.g., from different tabs). Behavior:
  • Each request returns a valid but different access token
  • Last token stored wins
  • Previous tokens remain valid until expiration
Prevention:

Concurrent Onboarding and Login

User attempting login while still in registration flow. Scenario:
Handling: Some phases may provide a temporary token for registration API calls. Check both accessToken and phase:

Complete Integration Example

Full production-ready login implementation with comprehensive error handling.

Testing Different Scenarios

Use these test cases to verify your integration handles all scenarios correctly:
Setup:
  • Valid email and password
  • No OTP enabled
  • Onboarding complete
Expected Result:
  • HTTP 200
  • Valid accessToken returned
  • isOtpRequired: false
  • phase: null
Verification:
Setup:
  • Valid email and password
  • OTP enabled on account
Expected Result:
  • HTTP 200 on initial login with isOtpRequired: true
  • HTTP 200 on OTP send
  • HTTP 200 on final login with valid accessToken
Verification:
Setup:
  • Invalid email or password
Expected Result:
  • HTTP 401
  • Error message: “Invalid email or password”
Verification:
Setup:
  • Valid credentials
  • User has not completed onboarding
Expected Result:
  • HTTP 200
  • accessToken: null
  • phase: "PHONE_NUMBER" (or other phase)
Verification:
Setup:
  • Account locked due to failed attempts
Expected Result:
  • HTTP 403
  • Error message about account lock
Verification:

Send OTP

Send OTP verification code via SMS for 2FA authentication

Logout

Invalidate access token and end user session

OAuth Authorize

Generate authorization code for OAuth 2.0 token exchange

Get User Profile

Retrieve authenticated user’s profile and verification status
For detailed authentication flows and patterns, see the Authentication Guide.