> ## 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.

# Cuentas, aplicaciones y entornos

> El modelo que debes entender antes de tu primera llamada: inicios de sesión, cuentas personales y comerciales, tipos y estados de aplicaciones, y qué token necesita cada operación.

La mayoría de los problemas de integración de la primera semana provienen de una de cuatro confusiones: a qué **cuenta** pertenece un token, qué **tipo** de aplicación creaste, en qué **estado** está esa aplicación y a qué **entorno** estás llamando. Esta página explica las cuatro.

## Inicios de sesión y cuentas

Un **usuario** de Fluz es un inicio de sesión: una persona con un correo, número de teléfono, PIN y verificación de identidad. Un usuario puede tener varias **cuentas**:

| Cuenta               | Cómo llega a existir                                                                        | Verificada por                 | Tipo de cuenta del token |
| :------------------- | :------------------------------------------------------------------------------------------ | :----------------------------- | :----------------------- |
| **Cuenta personal**  | Se crea automáticamente cuando el usuario se registra o es dado de alta con `registerUser`  | KYC de la persona              | `CONSUMER`               |
| **Cuenta comercial** | Creada por `registerBusiness` y aprobada mediante KYB. Un usuario puede ser dueño de varias | KYB de la entidad y sus dueños | `BUSINESS`               |

<Warning>
  Una cuenta personal nunca se *convierte* en una cuenta comercial. Una cuenta comercial es una cuenta separada, propiedad del usuario, que cobra existencia a través de KYB. La cuenta personal sigue existiendo junto a ella.
</Warning>

"Personal" (en el panel) y `CONSUMER` (en la API) significan lo mismo.

Las billeteras, cuentas de gasto, tarjetas y transacciones pertenecen a una **cuenta**, no al usuario. El mismo usuario actuando a través de su cuenta personal y de su cuenta comercial ve dos libros contables separados.

## Cada token está vinculado a una cuenta

`generateUserAccessToken` recibe un `userId` **y** un `accountId`. El `accountId` decide por cuál cuenta actúa el token:

* el `accountId` personal del usuario otorga un token `CONSUMER`;
* un `accountId` de negocio otorga un token `BUSINESS`.

Para ver todas las cuentas que posee un usuario, y el ID de cada cuenta, usa [Obtener cuentas](/recipes/get-accounts).

La mayoría de las operaciones aceptan cualquiera de los dos tipos de token y actúan sobre la cuenta a la que pertenece el token. Unas pocas requieren específicamente un tipo:

| Operación                              | Tipo de cuenta de token requerido | Por qué                                       |
| :------------------------------------- | :-------------------------------- | :-------------------------------------------- |
| `getBusinessCategories`                | `CONSUMER`                        | Se llama antes de que exista el negocio       |
| `registerBusiness`                     | `CONSUMER`                        | La persona aplica; el negocio aún no existe   |
| `getBusiness`                          | `BUSINESS`                        | Lee el negocio al que pertenece el token      |
| `requestOwnerDocumentVerificationLink` | `BUSINESS`                        | Actúa sobre la lista de dueños de ese negocio |

Enviar el tipo incorrecto devuelve `AUTH-0002` con un mensaje que nombra el tipo requerido, por ejemplo `getBusinessCategories requires account type CONSUMER`. Genera un token con el otro `accountId` y vuelve a intentar.

## Dos tipos de aplicación

Dónde haces clic en el área de **Developers** decide lo que puede hacer tu aplicación.

| Creada desde                      | Puede actuar sobre                                      | Úsala para                                                                    |
| :-------------------------------- | :------------------------------------------------------ | :---------------------------------------------------------------------------- |
| **Create new app**                | Solo la cuenta del propio desarrollador                 | Scripts y automatización de back-office en tu propia cuenta de Fluz           |
| **Templates → OAuth Integration** | Las cuentas de otros usuarios, una vez que te autoricen | Plataformas: registrar clientes, ejecutar KYC/KYB, emitir tarjetas para ellos |

<Note>
  Si vas a crear usuarios, verificarlos o emitir tarjetas en nombre de alguien más que no seas tú mismo, necesitas una aplicación de **OAuth Integration**. Una app creada con **Create new app** no se puede actualizar a eso. Crea una nueva app desde la plantilla.
</Note>

## Estado de la aplicación

Las aplicaciones nuevas no inician activas.

| Estado                                 | Para quién puede actuar la app                                                      |
| :------------------------------------- | :---------------------------------------------------------------------------------- |
| `PERSONAL`                             | Solo el desarrollador que la creó                                                   |
| `REVIEW` (mostrado como **In Review**) | Solo el desarrollador que la creó                                                   |
| `ACTIVE`                               | Otros usuarios de Fluz, mediante OAuth y llamadas de plataforma como `registerUser` |

Fluz mueve las aplicaciones a `ACTIVE`; no es autoservicio. Después de crear una aplicación, envía su nombre o ID a tu contacto en Fluz. Hasta entonces, las llamadas que actúan por otros usuarios devuelven:

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

<Warning>
  `current status: PERSONAL` en este error es el estado de la **aplicación**, no tu tipo de cuenta. Convertir o cambiar de cuentas no lo solucionará. Pide a Fluz que active la aplicación.
</Warning>

Algunas capacidades también se habilitan por aplicación además de `ACTIVE`, por ejemplo `registerUser` y el alcance `VERIFY_KYC`. Cada entorno habilita su aplicación por separado.

## Entornos

Staging y live son sistemas separados:

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

Cada entorno tiene sus propios usuarios, cuentas, aplicaciones y llaves de API. Una llave de uno nunca funciona en el otro. Una aplicación que crees mientras has iniciado sesión en `fluz.app` es una aplicación **live**, incluso si solo pretendes hacer pruebas con ella.

## Juntándolo todo

Una plataforma que incorpora negocios, como un programa de tarjetas para sus propios clientes, usualmente se ve así en staging:

1. Tienes una aplicación de **OAuth Integration**, propiedad de la cuenta de tu empresa, que Fluz movió a `ACTIVE`.
2. Para cada cliente, haces `registerUser` de la persona, la verificas y la envías por OAuth. Tu token para esa persona es `CONSUMER`.
3. Con ese token `CONSUMER` llamas a `getBusinessCategories` y `registerBusiness`.
4. Una vez que KYB aprueba el negocio, generas un token `BUSINESS` (mismo `userId`, `accountId` del negocio) y emites tarjetas y mueves dinero en el negocio.

Consulta [Incorporar y verificar un negocio](/quickstart/onboard-businesses) para la versión ejecutable.