Authenticate User
Authentication
Authenticate User
Authenticate user with email and password to obtain an access token
POST
Authenticate User
Overview
Authenticate a user with their credentials to obtain an access token. This endpoint is used in two contexts:- OAuth Step 2 (API Mode): When using
mode=apiin OAuth flow, this step authenticates the user to get an access token needed for Step 3 - Direct Login: For applications not using OAuth, this provides immediate access token for API authentication
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
Your public API client key
Set to
true to route requests to the US backend environmentDefault: false (international environment)Body Parameters
User’s email addressFormat: Valid emailExample:
user@example.comUser’s passwordFormat: Password stringExample:
SecurePassword123!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: 123456Response
Access token for API authenticationUse this in
Authorization: Bearer header for authenticated endpointsExpiry: 6 hoursExample: US_b6b9168a-bb56-4c6a-9c0d-4650ea74f5f9User’s unique identifierFormat: UUIDExample:
b6b9168c-bb56-4c6a-9c0d-4650ea74f5f9Indicates if user requires OTP verificationIf
true, you must:- Call
POST /v1/auth/login/otpto send OTP code - Retry this endpoint with
otpCodeparameter
falseMasked phone number (only returned if
isOtpRequired is true)Example: +445*****225User onboarding phase (only returned during onboarding)Possible values:
ACCOUNTPHONE_NUMBERPERSONAL_INFORMATIONPHYSICAL_ADDRESSMAILING_ADDRESS
nullUser’s KYC verification statusPossible values:
UNVERIFIED- No verification submittedPENDING- Verification in progressVERIFIED- Successfully verifiedREJECTED- Verification failed
VERIFIEDIndicates if client has valid permission to access user’s accountIn OAuth context,
false means authorization hasn’t been granted yetExample: falseSuccess Response
Error Responses
400 Bad Request - Invalid Credentials
400 Bad Request - Invalid Credentials
- Incorrect email or password
- Account doesn’t exist
- Account is locked or disabled
400 Bad Request - OTP Required
400 Bad Request - OTP Required
POST /v1/auth/login/otp first, then retry with otpCode422 Validation Error
422 Validation Error
- 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
Onboarding Phase: If
phase is not null, the user hasn’t completed registration. Guide them through the remaining onboarding steps before allowing full access.Failed Login Attempts
After multiple failed login attempts, accounts may be temporarily locked:Token Storage Security
Always store access tokens securely:- Web apps: Use
httpOnlycookies 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:| accessToken | isOtpRequired | phase | Action Required |
|---|---|---|---|
| non-null | false | null | Success: Store token, proceed with API calls |
| null | true | null | OTP Flow: Call /v1/auth/login/otp, collect code, retry with otpCode |
| null | false | non-null | Onboarding: Direct user to complete registration at specified phase |
| non-null | false | non-null | Partial Onboarding: Token valid but registration incomplete |
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:- Store
accessTokensecurely (sessionStorage, secure storage) - Track token issuance time for expiration handling
- Use token in
Authorization: Bearerheader for all API calls - If
isLinked: falseand long-lived access needed, initiate OAuth flow
HTTP 200: OTP Required
User has 2FA enabled. Initial authentication succeeded but OTP verification required. Response:accessToken is null:
The token won’t be issued until OTP verification completes. This prevents unauthorized access even if credentials are compromised.
Client Action:
- Call
POST /v1/auth/login/otpwithuserIdto send OTP - Display OTP input field to user
- Show masked
phoneNumberso user knows where to check - Retry
POST /v1/auth/loginwith credentials +otpCodeparameter - Handle OTP-specific errors (invalid code, expired code, rate limit)
See Send OTP for detailed OTP endpoint documentation.
HTTP 200: User Onboarding Incomplete
User account exists but hasn’t completed registration. Response:ACCOUNT: Basic account creation (email/password set)PHONE_NUMBER: Phone verification requiredPERSONAL_INFORMATION: Name, DOB, SSN collectionPHYSICAL_ADDRESS: Residential address informationMAILING_ADDRESS: Mailing address (if different from physical)
- Direct user to continue registration at the specified phase
- Do NOT attempt API calls -
accessTokenis null - Guide user through onboarding steps
- After completion,
phasewill benullandaccessTokenwill be provided
HTTP 401: Invalid Credentials
Incorrect email/password combination or account doesn’t exist. Response:- Typo in email or password
- User hasn’t registered yet
- Password changed but old credentials used
- Testing with wrong environment credentials
- Display generic error message to user (don’t specify which field is wrong)
- Implement rate limiting on client side (exponential backoff)
- Offer “Forgot Password” option after 2-3 failed attempts
- After 5 failed attempts, suggest account recovery
HTTP 403: Account Locked
Account temporarily locked due to security concerns. Response:- Multiple failed login attempts (brute force protection)
- Suspicious activity detected
- Manual lock by admin/support
- Security policy violation
- Display error message with support contact information
- Do NOT retry immediately - will extend lock duration
- Implement exponential backoff (start with 1 hour delay)
- Provide link to account recovery/support
HTTP 422: Validation Error
Request parameters failed validation. Response:email must be a valid email: Invalid email formatpassword is required: Missing password fieldotpCode must be 6 digits: Invalid OTP code format
- Validate input on client side before submission
- Display field-specific error messages
- Highlight invalid fields in UI
- Prevent submission until validation passes
Edge Cases
Multiple Failed OTP Attempts
After 3-5 failed OTP verification attempts, the account may be temporarily locked. Response:Expired OTP Code
OTP codes typically expire after 5-10 minutes. Response:Environment Mismatch
Using production credentials in sandbox or vice versa. Symptoms:- 401 errors despite correct credentials
- User not found errors
- Token format mismatch errors
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
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
Concurrent Onboarding and Login
User attempting login while still in registration flow. Scenario: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:Test Case 1: Successful Login
Test Case 1: Successful Login
Setup:
- Valid email and password
- No OTP enabled
- Onboarding complete
- HTTP 200
- Valid
accessTokenreturned isOtpRequired: falsephase: null
Test Case 2: OTP Flow
Test Case 2: OTP Flow
Setup:
- Valid email and password
- OTP enabled on account
- HTTP 200 on initial login with
isOtpRequired: true - HTTP 200 on OTP send
- HTTP 200 on final login with valid
accessToken
Test Case 3: Invalid Credentials
Test Case 3: Invalid Credentials
Setup:
- Invalid email or password
- HTTP 401
- Error message: “Invalid email or password”
Test Case 4: User Onboarding
Test Case 4: User Onboarding
Setup:
- Valid credentials
- User has not completed onboarding
- HTTP 200
accessToken: nullphase: "PHONE_NUMBER"(or other phase)
Test Case 5: Account Locked
Test Case 5: Account Locked
Setup:
- Account locked due to failed attempts
- HTTP 403
- Error message about account lock
Related Endpoints
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.