Skip to Content
B2C APIUser Endpoints

User Endpoints

The following outlines the endpoints for posting, updating and managing statuses of users registered within the Orca system. These endpoints do not initiate User risk screening, which must be done using the Onboard request instead of the User request.

User onboarding

If you have any additional fields you capture when onboarding a user, feel free to let us know at support@orca-fraud.com

Create or Update User

Submit user information to create a new user or update an existing one.

Endpoint: POST /v1/user

Request Schema

FieldTypeRequiredDescription
idstringYesUnique user identifier
timestampnumberYesUnix epoch milliseconds. Must not be in the future
firstNamestringNoUser’s first name
lastNamestringNoUser’s last name
dateOfBirthstringNoISO format date (YYYY-MM-DD)
addressobjectNoUser’s address details
companystringNoCompany name for grouping users
phone.phonestringNoPhone number in E.164 format
phone.countrystringNoISO 3166-1 alpha-2 country code
phone.isVerifiedbooleanNoWhether phone has been verified
email.emailstringNoUser’s email address
email.isVerifiedbooleanNoWhether email has been verified
documentsarrayNoUser identification documents
lastLoginnumberNoTimestamp of last user login
userDeviceobjectNoUser’s device information, if not sent using /userDevice endpoint
statusenumNoUser status: ACTIVE, INACTIVE, BLOCKED, plus the aliases PENDING and APPROVED (both stored as active) and DECLINED (stored as inactive)
amlDetail.amlStatusstringNoAML verification status
amlDetail.amlSourcestringNoSource of AML verification
kycDetail.sourceOfIncomestringNoUser’s income source
kycDetail.kycStatusstringNoKYC verification status
kycDetail.kycSourcestringNoSource of KYC verification
kycDetail.kycStatusMessagestringNoAdditional KYC status details
salary.cycleenumNoSalary payment frequency: weekly, bi-weekly, monthly, if applicable
salary.amountnumberNoSalary amount, if applicable
salary.currencystringNoSalary currency code, if applicable
referralCodestringNoReferral code of user, if applicable
referrerCodestringNoReferral code used by user to register, if applicable
taxNumberIdstringNoTax identification number for the user
guestbooleanNoWhether this is a guest user rather than a registered account

Request Body

{ "id": "USER123", "firstName": "John", "lastName": "Doe", "dateOfBirth": "1990-01-01", "email": { "email": "john@example.com", "isVerified": false }, "lastLogin": 1734167723000, "timestamp": 1734167723000 }

Response

{ "id": "USER123", "status": "success" }

Responses

  • 200: User processed successfully
  • 400: Bad request
  • 500: Internal server error

Submit User Feedback

Submit feedback to update user status and details after user onboarding.

Endpoint: POST /v1/user/feedback

Request Schema

FieldTypeRequiredDescription
userIdstringYesIdentifier of the user the feedback concerns
onboardingFeedbackobjectYesThe onboarding outcome. The whole object is required
onboardingFeedback.statusenumYesOutcome: PENDING, APPROVED, DECLINED, BLOCKED
onboardingFeedback.descriptionstringYesDescription of the outcome
onboardingFeedback.createdAtnumberYesUnix epoch milliseconds
onboardingFeedback.idstringNoYour own identifier for this feedback
onboardingFeedback.typestringNoType of feedback, for example KYC
amlDetail.amlStatusstringNoAML verification status
amlDetail.amlSourcestringNoSource of AML verification
kycDetail.sourceOfIncomestringNoUser’s income source
kycDetail.kycStatusstringNoKYC verification status
kycDetail.kycSourcestringNoSource of KYC verification
kycDetail.kycStatusMessagestringNoAdditional KYC status details
referralCodestringNoReferral code of the user, if applicable
referrerCodestringNoReferral code the user registered with, if applicable

Note that the onboardingFeedback status values here are the onboarding outcomes, not the six user status values accepted by POST /v1/user.

Request Body

{ "userId": "USER123", "onboardingFeedback": { "id": "FEEDBACK123", "status": "APPROVED", "description": "All verification checks passed", "createdAt": 1734167723000, "type": "KYC" }, "kycDetail": { "sourceOfIncome": "employment", "kycStatus": "verified", "kycSource": "jumio", "kycStatusMessage": "Identity verified successfully" }, "amlDetail": { "amlStatus": "cleared", "amlSource": "refinitiv" } }

Response

{ "message": "Feedback processed successfully", "userId": "USER123" }

Responses

  • 200: Feedback processed
  • 400: Validation failed
  • 404: User not found
  • 500: Internal server error

Error Response Format

See the Error Reference section for a full description of API errors. Most API errors follow a consistent JSON structure:

{ "error": { "type": "ERROR_TYPE", "message": "Human-readable error description", "details": ["Additional error details (optional)"] }, "timestamp": 1755602195137 }

In the case of a validation error, the format will be as follows:

{ "error": { "type": "VALIDATION_ERROR", "message": "Request validation failed", "details": [ "/id: Expected string" ] }, "timestamp": 1755602195137 }

Get User by ID

Retrieve a specific user’s information by their ID.

Endpoint: GET /v1/users/{userId}

Parameters

ParameterTypeRequiredDescription
userIdstringYesUnique identifier for the user

Response Example

{ "user": { "id": "USER123", "createdAt": 1734067723000, "updatedAt": 1734167723000, "firstName": "John", "lastName": "Doe", "status": "active", "reason": "User previously blocked for suspicious activity" } }

Responses

  • 200: User retrieved successfully
  • 404: User not found
  • 500: Internal server error

Get User by Transaction ID

Retrieve user information associated with a specific transaction.

Endpoint: GET /v1/users/transactions/{transactionId}

Parameters

ParameterTypeRequiredDescription
transactionIdstringYesUnique identifier for the transaction

Response Example

{ "user": { "id": "USER123", "createdAt": 1734067723000, "updatedAt": 1734167723000, "firstName": "John", "lastName": "Doe", "status": "active", "reason": "User previously blocked for suspicious activity" } }

Responses

  • 200: User information retrieved successfully
  • 404: Transaction or associated user not found
  • 500: Internal server error

Block User

Block a specific user by their ID.

Endpoint: PUT /v1/users/{userId}/block

Request Body

{ "comment": "Suspicious activity detected", "reviewer": "john.smith" }

Responses

  • 200: Request accepted. A user.status.block webhook is delivered if the user’s status actually changed
  • 400: Bad request
  • 500: Internal server error

Unblock User

Unblock a specific user by their ID.

Endpoint: PUT /v1/users/{userId}/unblock

Request Body

{ "comment": "User verified identity", "reviewer": "jane.doe" }

Responses

  • 200: Request accepted. A user.status.unblock webhook is delivered if the user’s status actually changed
  • 400: Bad request
  • 500: Internal server error

Update User Status

Update a specific user’s status, this can be used instead of or in addition to the /block and /unblock endpoints.

Endpoint: PUT /v1/users/{userId}/status

Parameters

ParameterTypeRequiredDescription
userIdstringYesUnique identifier for the user

Request Schema

FieldTypeRequiredDescription
statusenumNoUser status: active, inactive
completedAtnumberNoTimestamp when status change was completed
closureTypestringNoClosure reason: sling_initiated, user_requested, user_requested_with_data_deletion
commentstringNoAdditional details about status change
initiatedBystringNoPerson or system initiating the status change
reasonstringNoPredefined reason code: NO_REASON, FINANCIAL_CRIME, RISK_TOLERANCE, FRAUDULENT_ACTIVITY, LINKED_TO_FRAUD

Request Body Example

{ "status": "inactive", "closureType": "user_requested", "comment": "User requested account closure", "initiatedBy": "support.team", "reason": "NO_REASON", "completedAt": 1734167723000 }

Responses

  • 200: Request accepted
  • 400: Bad request
  • 500: Internal server error

Get Blocked Users

Retrieve a list of blocked users with pagination support.

Endpoint: GET /v1/users/blocked

Query Parameters

  • start (optional): Cursor for pagination
  • limit (optional): Number of users to return (default: 100)

Response Example

{ "users": [ { "id": "USER123", "status": "BLOCKED", "updatedAt": 1734167723000 }, { "id": "USER456", "status": "BLOCKED", "updatedAt": 1734167723000 } ], "total": 45, "cursor": "USER456" }

Responses

  • 200: List of blocked users retrieved successfully
  • 400: Bad request
  • 500: Internal server error

Update Transaction User Status

Update the status of users involved in a specific transaction.

Endpoint: PUT /v1/users/transactions/{transactionId}/status

Parameters

ParameterTypeRequiredDescription
transactionIdstringYesUnique identifier for the transaction

Request Schema

FieldTypeRequiredDescription
statusenumNoUser status to apply: active, inactive, blocked (lowercase)
partiesenumNoWhich parties to update: both, user, recipient (defaults to user)
commentstringNoAdditional details about status change
reviewerstringNoPerson or system initiating the status change

Request Body Example

{ "status": "blocked", "parties": "user", "comment": "Fraudulent transaction detected", "reviewer": "fraud.detection.team" }

Responses

  • 200: User status updated successfully
  • 404: Transaction not found
  • 500: Internal server error

Update Users by Attribute

Update the status of all users that match a specific attribute. This is useful for blocking users with shared suspicious attributes.

Endpoint: PUT /v1/users/attributes/status

Request Schema

FieldTypeRequiredDescription
attributeenumYesAttribute to match: phone, email, ipAddress, deviceFingerprint, bankAccountNumber, cryptoAddress, walletTaxNumberId, walletPhone, cardFingerprint
valuestringYesValue of the attribute to match
statusenumNoStatus to apply to matching users: ACTIVE, INACTIVE, BLOCKED, plus the aliases PENDING and APPROVED (both stored as active) and DECLINED (stored as inactive)
commentstringNoAdditional details about status change
reviewerstringNoPerson or system initiating the status change

Request Body Example

{ "attribute": "deviceFingerprint", "value": "fp_abcdef123456", "status": "BLOCKED", "comment": "Device linked to multiple fraudulent accounts", "reviewer": "risk.team" }

Responses

  • 200: Users updated successfully. The response body reports how many users matched
  • 400: attribute and value are required, or attribute is not one of the supported values
  • 500: Internal server error

Schema Definitions

User Schema

type UserStatus = | 'ACTIVE' | 'INACTIVE' | 'BLOCKED' // stored as-is | 'PENDING' | 'APPROVED' // both stored as active | 'DECLINED'; // stored as inactive interface User { id: string; // Unique user identifier timestamp: number; // Unix timestamp in milliseconds, must not be in the future firstName?: string; lastName?: string; dateOfBirth?: string; // Required for age-related rules address?: Address; company?: string; // Company name for grouping users taxNumberId?: string; guest?: boolean; // Guest rather than a registered account phone?: { phone: string; // E.164 formatted country?: string; // ISO 3166-1 alpha-2 isVerified?: boolean; }; email?: { email: string; isVerified?: boolean; }; documents?: UserDocument[]; lastLogin?: number; userDevice?: UserDevice; status?: UserStatus; amlDetail?: { amlStatus?: string; amlSource?: string; }; kycDetail?: { sourceOfIncome?: string; kycStatus?: string; kycSource?: string; kycStatusMessage?: string; }; salary?: { cycle: 'weekly' | 'bi-weekly' | 'monthly'; amount: number; currency: string; // ISO 4217 }; onboardingFeedback?: { id?: string; status?: UserStatus; description?: string; createdAt?: number; type?: string; }; referralCode?: string; referrerCode?: string; }

UserDocument Schema

interface UserDocument { country?: string; // Country of document issue number?: string; // Document identification number type?: string; // Document type (passport, ID card, driver's license) source?: string; // Source of document verification fullName?: string; // Full name as appears on the document }
Last updated on