Skip to main content
Before anyone can hold value or move money on Fluz, two things have to be true: an account exists, and the identity behind it has been verified. This section covers doing both programmatically. There are two tracks — individuals and businesses — and a business track always contains an individual one.

Individuals (KYC)

registerUser creates the account. verifyUserInformation verifies the person. Verification is synchronous, with a hard limit on attempts.

Businesses (KYB)

registerBusiness creates the entity and starts verification. The result is asynchronous — the account opens in PENDING and resolves later.
Both are restricted. User registration requires permission granted by Fluz per application; business registration requires the REGISTER_BUSINESS scope. Talk to your account manager before building against either.

​
Do you need to do this at all?

You don’t have to own onboarding. An embedded widget runs registration, verification, and consent as a hosted flow, keeping identity data inside Fluz’s compliance scope. Register users yourself when you already hold clean, verified profile data. If you’d be collecting date of birth and SSN purely to forward them, use the widget — you’re taking on regulated data handling for no benefit.

​
The individual track

1

Register

registerUser with first name, last name, phone, region code, email, and date of birth (YYYY-MM-DD).Names should match the documents the user will verify with. A mismatch resurfaces at step 2 as a decline that’s much harder to diagnose.→ User Registration
2

Verify

verifyUserInformation runs KYC. Users must be verified to transact at all, or to transact at higher limits.→ User KYC Verification
3

Get authorized

Registering someone does not give you permission to act for them. That’s a separate, explicit grant.→ Client-facing OAuth grant flow

​
Verification outcomes

Three attempts, then the door closes. Validate aggressively before calling — address formatting, name spelling, date format — because a typo burns one of three tries. Never put verifyUserInformation behind an automatic retry loop.

​
”Already in use” is normal

registerUser returns AUTH-0026 (phone) or AUTH-0027 (email) when the person already has a Fluz account. Fluz accounts aren’t scoped to your application, so anyone who has used Fluz before — through any app or the consumer product — already exists. That’s a routing signal, not a failure. Send them through the grant flow to authorize the account they already have. Build this as the normal path, not an error branch.

​
The business track

KYB has more moving parts and a strict order.
1

Register the primary owner as a user first

This is the dependency people miss. The primary business owner must already be a registered Fluz user, and the emailAddress on the owner record must be the one they registered with. Register the human before you register the company.
2

Fetch valid categories

getBusinessCategories returns the businessCategoryId and businessSubCategoryId values you’ll need. Don’t hard-code them, and don’t mix a subcategory from one category with another — that’s BS-0006.→ Business Categories
3

Upload a document, if sole proprietorship

SOLE_PROPRIETORSHIP requires a supporting document, uploaded first via a REST endpoint as form-data. Pass the returned URL as soleProprietorshipDocumentUrl.
4

Register the business

registerBusiness with the entity details, legal address, tax ID, categories, account usage, and owners. Returns an accountId and a kybStatus of PENDING.→ Business Registration
5

Wait for KYB to resolve

The account stays PENDING until verification completes.

​
Constraints worth knowing before you build

Date of birth is formatted differently in the two flows. registerUser takes dateOfBirth as YYYY-MM-DD. BusinessOwner.dob takes MM/DD/YYYY. Same concept, adjacent pages, opposite formats — and a wrong format here costs you a failed registration or a burned KYC attempt.

​
Scopes and permissions

Enable scopes on the app’s Permissions tab before building. A scope you request but haven’t enabled is silently dropped rather than rejected. → Configure OAuth App

​
Errors come back in data

Both registerUser and registerBusiness report failure as an HTTP 200 with success: false and a populated error object — not as entries in the GraphQL errors array. Code that only inspects errors will read every failure as a success. Check all three layers: transport errors, then success, then branch on error.code.

​
Handling the data

This section moves more regulated data than anywhere else in the API: full names, dates of birth, SSN digits, home addresses, identity documents.
  • Send it from your server over TLS. Never from a browser or mobile client.
  • Keep it out of logs, error-tracking payloads, and analytics.
  • Validate formats locally before calling, both to avoid burning KYC attempts and to avoid transmitting data twice.
  • Have an answer ready for how long you retain it and why. Your enterprise customers will ask.
If none of that is appealing, that’s the case for the widget.

​
Testing

Staging mirrors these flows without real verification against real people. Never register real individuals or businesses in staging, and never carry staging test identities into production. → Testing KYC Flows · Test Addresses · Staging vs. Live

​
In this section

User registration

Create an individual account.

User KYC verification

Verify the person behind it.

Business registration

Create an entity and start KYB.

Business categories

Valid category and subcategory IDs.

Formatting referral links

Bring users in through a referral.

Embedded widgets

Hand the whole flow to Fluz instead.