> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluz.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Accounts, applications & environments

> The model to understand before your first call: logins, personal and business accounts, application types and statuses, and which token each operation needs.

Most first-week integration problems come from one of four mix-ups: which **account** a token belongs to, which **type** of application you created, what **status** that application is in, and which **environment** you are calling. This page explains all four.

## Logins and accounts

A Fluz **user** is a login: one person with an email, phone number, PIN, and identity verification. A user can hold several **accounts**:

| Account              | How it comes to exist                                                             | Verified by                      | Token account type |
| :------------------- | :-------------------------------------------------------------------------------- | :------------------------------- | :----------------- |
| **Personal account** | Created automatically when the user signs up or is registered with `registerUser` | KYC on the person                | `CONSUMER`         |
| **Business account** | Created by `registerBusiness` and approved through KYB. A user can own several    | KYB on the entity and its owners | `BUSINESS`         |

<Warning>
  A personal account is never *converted* into a business account. A business account is a separate account, owned by the user, that comes into existence through KYB. The personal account keeps existing alongside it.
</Warning>

"Personal" (in the dashboard) and `CONSUMER` (in the API) mean the same thing.

Wallets, spend accounts, cards and transactions all belong to an **account**, not to the user. The same user acting through their personal account and through their business account sees two separate ledgers.

## Every token is bound to one account

`generateUserAccessToken` takes a `userId` **and** an `accountId`. The `accountId` decides which account the token acts as:

* the user's personal `accountId` gives a `CONSUMER` token;
* a business `accountId` gives a `BUSINESS` token.

To see every account a user holds, and each account's ID, use [Get Accounts](/recipes/get-accounts).

Most operations accept either token type and act on whichever account the token belongs to. A few require one type specifically:

| Operation                              | Required token account type | Why                                                |
| :------------------------------------- | :-------------------------- | :------------------------------------------------- |
| `getBusinessCategories`                | `CONSUMER`                  | Called before the business exists                  |
| `registerBusiness`                     | `CONSUMER`                  | The person applies; the business doesn't exist yet |
| `getBusiness`                          | `BUSINESS`                  | Reads the business that the token belongs to       |
| `requestOwnerDocumentVerificationLink` | `BUSINESS`                  | Acts on that business's owner roster               |

Sending the wrong type returns `AUTH-0002` with a message naming the type required, for example `getBusinessCategories requires account type CONSUMER`. Mint a token with the other `accountId` and retry.

## Two kinds of application

Where you click in the **Developers** area decides what your application can do.

| Created from                      | Can act on                                     | Use it for                                                                |
| :-------------------------------- | :--------------------------------------------- | :------------------------------------------------------------------------ |
| **Create new app**                | Only the developer's own account               | Scripts and back-office automation on your own Fluz account               |
| **Templates → OAuth Integration** | Other users' accounts, once they authorize you | Platforms: registering customers, running KYC/KYB, issuing cards for them |

<Note>
  If you will create users, verify them, or issue cards on anyone's behalf other than your own, you need an **OAuth Integration** application. An app made with **Create new app** cannot be upgraded into one. Create a new app from the template instead.
</Note>

## Application status

New applications do not start active.

| Status                            | Who the app can act for                                                   |
| :-------------------------------- | :------------------------------------------------------------------------ |
| `PERSONAL`                        | Only the developer who created it                                         |
| `REVIEW` (shown as **In Review**) | Only the developer who created it                                         |
| `ACTIVE`                          | Other Fluz users, through OAuth and platform calls such as `registerUser` |

Fluz moves applications to `ACTIVE`; it isn't self-serve. After you create an application, send its name or ID to your Fluz contact. Until then, calls that act for other users return:

```text theme={null}
AUTH-0030  Application <app_id> is not active (current status: PERSONAL)
```

<Warning>
  `current status: PERSONAL` in this error is the **application's** status, not your account type. Converting or switching accounts will not fix it. Ask Fluz to activate the application.
</Warning>

Some capabilities are also enabled per application on top of `ACTIVE`, for example `registerUser` and the `VERIFY_KYC` scope. Each environment's application is enabled separately.

## Environments

Staging and live are separate systems:

|                  | Staging (sandbox)                                        | Live                                             |
| :--------------- | :------------------------------------------------------- | :----------------------------------------------- |
| Web app          | `uni.staging.fluzapp.com`                                | `fluz.app`                                       |
| Developers area  | `uni.staging.fluzapp.com/for-developers`                 | `fluz.app/for-developers`                        |
| GraphQL endpoint | `transactional-graph.staging.fluzapp.com/api/v1/graphql` | `transactional-graph.fluzapp.com/api/v1/graphql` |

Each environment has its own users, accounts, applications, and API keys. A key from one never works in the other. An application you create while logged in to `fluz.app` is a **live** application, even if you only intend to test with it.

## Putting it together

A platform that onboards businesses, such as a card program for its own clients, usually looks like this in staging:

1. You have an **OAuth Integration** application, owned by your company's account, moved to `ACTIVE` by Fluz.
2. For each customer, you `registerUser` the person, verify them, and send them through OAuth. Your token for them is `CONSUMER`.
3. With that `CONSUMER` token you call `getBusinessCategories` and `registerBusiness`.
4. Once KYB approves the business, you mint a `BUSINESS` token (same `userId`, business `accountId`) and issue cards and move money on the business.

See [Onboard & Verify a Business](/quickstart/onboard-businesses) for the runnable version.