> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Socios
> Da a cada uno de tus clientes credenciales propias y limita qué puede hacer, dónde, desde qué direcciones y por cuánto tiempo.
Esta funcionalidad está disponible solo en Staging para pruebas y todavía no está disponible en Producción.
Un socio es uno de tus propios clientes que llama a tu plataforma Lerian desde sus propios sistemas. Access Manager permite dar a cada socio credenciales propias. Tú decides qué puede hacer el socio, en qué parte de tus datos, desde qué direcciones de red y por cuánto tiempo.
Piensa en un edificio con muchas oficinas. Tú eres el dueño y tienes todas las llaves. Un socio recibe una credencial que abre solo las puertas que eliges, funciona solo en el horario que defines y deja de funcionar en el momento en que la cancelas.
## Por qué segregar el acceso
***
Cuando varios clientes llaman a tu plataforma, una credencial compartida da a cada uno de ellos el acceso de todos. Los socios reemplazan eso por un conjunto de límites para cada cliente:
* **Mínimo privilegio.** Cada socio recibe solo las acciones y los datos que necesita, y nada por encima de lo que tu propio equipo puede hacer.
* **Credenciales por socio.** Cada socio tiene sus propias credenciales. Puedes revocar un socio sin tocar a los demás.
* **Revocación inmediata.** Suspender un socio, o llegar al fin de su ventana de validez, rechaza su siguiente solicitud, incluso con un token que ya tiene.
* **Restricción de red.** Un socio solo puede llamar desde las direcciones que listas para él.
* **Ventanas de validez.** El acceso puede empezar y terminar en las fechas que eliges. Un piloto que termina en una fecha no necesita un recordatorio para apagarse.
* **Responsabilidad clara.** Cada solicitud lleva la credencial del propio socio, así que cada acción apunta a un único socio.
## Los bloques de construcción
***
Un tenant contiene organizaciones, y una organización contiene ledgers. Un socio es un registro del tenant, y las filas que lo siguen describen lo que recibe un socio.
| Concepto | Qué es | Ejemplo |
| - | - | - |
| **Tenant** | Tu entorno en la plataforma Lerian. Tus usuarios, aplicaciones y socios viven dentro de él. | Un tenant para staging y otro para producción. |
| **Organización de Midaz** | Una empresa o unidad de negocio dentro de tu tenant. Un tenant puede tener varias organizaciones. | "Organización Norte" y "Organización Sur". |
| **Ledger** | Un conjunto de libros dentro de una organización de Midaz. Una organización puede tener varios ledgers. | "Ledger N1" y "Ledger N2" dentro de la Organización Norte. |
| **Socio** | Un registro dentro de tu tenant que representa a uno de tus propios clientes. Un socio no es un tenant. | "Socio A". |
| **Aplicación del socio** | Una credencial máquina a máquina (un client ID y un client secret) que pertenece a un socio. Un socio puede tener varias. | Una aplicación para Midaz y otra para Tracer. |
| **Permisos** | **Qué** puede hacer el socio: un producto, sus recursos y las acciones sobre ellos. | Midaz: `accounts` y `transactions`, con `get` y `post`. |
| **Ámbito** | **Dónde** puede hacerlo el socio: qué organización, qué ledgers, qué cuentas. Cada producto publica las restricciones que acepta. | Solo la Organización Norte, solo el Ledger N1. |
| **Techo** | Lo máximo que puedes dar a un socio en un producto: lo que tiene el rol de editor del producto en tu tenant. | Si tu tenant no puede eliminar cuentas, ningún socio puede. |
| **Lista de IP permitidas del socio** | Las direcciones de red desde las que pueden llamar las credenciales del socio. | Solo `203.0.113.10`. |
| **Ventana de validez y estado** | Cuándo funcionan las credenciales del socio (`validFrom` y `validUntil`) y si el socio está `active` o `suspended`. | Válido por 90 días, después rechazado. |
## Cómo encajan las piezas
***
El tenant es un límite rígido. Los datos de tu tenant de staging nunca se mezclan con los datos de tu tenant de producción. Dentro de un tenant, las organizaciones y los ledgers separan tus datos de forma **lógica**: Access Manager usa el ámbito de cada socio para mantener a cada socio dentro de su propia parte.
* **Tenant: Producción.** Tu tenant de staging es otro, separado.
* **Organización Norte**
* **Ledger N1.** El Socio A escribe cuentas y transacciones aquí.
* **Ledger N2**
* **Cuentas 1 y 2.** El Socio C lee solo estas dos cuentas.
* **Organización Sur.** El Socio B lee la organización entera, por 90 días.
* **Ledger S1**
* **Ledger S2**
Los tres socios viven en el mismo tenant. Ninguno de ellos ve la parte de otro.
## Ejemplo: tres socios en un tenant
***
Tu empresa usa un tenant por entorno. El tenant de producción tiene dos organizaciones de Midaz, Norte y Sur. Tres de tus clientes necesitan acceso a la API.
### Socio A: escribe en un ledger, desde una dirección
| Configuración | Valor |
| - | - |
| Permisos | Midaz: `accounts` con `get`, `post`, `patch`; `transactions` con `get`, `post` |
| Ámbito | Organización Norte, Ledger N1 |
| Lista de IP permitidas | Lista propia: `203.0.113.10/32` |
| Validez | Sin límite de tiempo |
| Solicitud | Resultado |
| - | - |
| Crear una transacción en el Ledger N1, desde `203.0.113.10` | Permitida. |
| Listar las cuentas del Ledger N1 | Permitida. |
| Listar las cuentas del Ledger N2 | Rechazada con `403`. El Ledger N2 está fuera de su ámbito. |
| Eliminar una cuenta en el Ledger N1 | Rechazada con `403`. `delete` no está en sus permisos. |
| Cualquier solicitud desde otra dirección | Rechazada con `403` y el código `AUT-0021`. |
Tampoco puedes dar al Socio A el derecho de crear ledgers. Crear un ledger actúa sobre toda la organización, que es más amplia que un ledger. Access Manager rechaza ese cambio con `IDE-1056`, y Console muestra la línea como "Outside the scope".
### Socio B: lee una organización entera por 90 días
| Configuración | Valor |
| - | - |
| Permisos | Midaz: `ledgers`, `accounts`, `balances`, `transactions`, todos con `get` |
| Ámbito | Organización Sur |
| Lista de IP permitidas | Usa la lista de tu tenant |
| Validez | `validFrom` `2026-11-01T00:00:00Z`, `validUntil` `2027-01-30T23:59:59Z` |
| Solicitud | Resultado |
| - | - |
| Leer los saldos de cualquier ledger de la Organización Sur, dentro de la ventana | Permitida. |
| Crear una transacción en la Organización Sur | Rechazada con `403`. Solo puede leer. |
| Leer cualquier cosa de la Organización Norte | Rechazada con `403`. La Organización Norte está fuera de su ámbito. |
| Cualquier solicitud antes de `2026-11-01T00:00:00Z` o después de `2027-01-30T23:59:59Z` | Rechazada con `401` y el código `AUT-1010`. Un token nuevo se rechaza con el mismo código. |
### Socio C: lee dos cuentas y después se suspende
| Configuración | Valor |
| - | - |
| Permisos | Midaz: `accounts`, `balances`, `transactions`, todos con `get` |
| Ámbito | Organización Norte, Ledger N2, dos IDs de cuenta |
| Lista de IP permitidas | Lista propia: `198.51.100.0/24` |
| Validez | Sin límite de tiempo |
| Solicitud | Resultado |
| - | - |
| Leer los saldos y las transacciones de sus dos cuentas | Permitida. Una restricción en una cuenta también cubre los saldos, las transacciones y las operaciones de esa cuenta. |
| Leer una tercera cuenta en el Ledger N2 | Rechazada con `403`. |
| Listar todas las cuentas del Ledger N2 | Rechazada con `403`. Cuando restringes un tipo por ID, el socio no puede listar ni crear elementos de ese tipo. |
| Cualquier solicitud después de que suspendes al Socio C | Rechazada con `401` y el código `AUT-1009`, también con un token emitido antes de la suspensión. Cuando lo reactivas, las mismas credenciales vuelven a funcionar. |
## Cómo se decide una solicitud
***
Las verificaciones de abajo se ejecutan en cada solicitud que la credencial de un socio envía a un producto. Se ejecutan en este orden, y la primera que falla detiene la solicitud.
1. **Token.** El sistema del socio cambia su client ID y su client secret por un token de acceso, y envía el token con la solicitud.
2. **Socio.** Access Manager encuentra el socio al que pertenece la credencial.
3. **Dirección de red.** Access Manager compara la dirección de quien llama con la lista propia del socio. Un socio sin lista propia usa la lista de tu tenant. Un rechazo devuelve `403` con `AUT-0021`.
4. **Estado y validez.** Un socio suspendido, o fuera de su ventana de validez, se rechaza con `401`: `AUT-1009` si está suspendido, `AUT-1010` si está fuera de la ventana.
5. **Permisos.** El producto, el recurso y la acción deben estar en los permisos del socio. Un rechazo devuelve `403`.
6. **Ámbito.** La organización, el ledger, la cuenta u otro elemento que nombra la solicitud debe estar dentro del ámbito del socio. Un rechazo devuelve `403`.
7. Si todas las verificaciones pasan, el producto ejecuta la solicitud.
El producto no dice a quien llama si fueron los permisos o el ámbito los que rechazaron la solicitud. Los dos devuelven el mismo `403`, así que un socio no puede usar los rechazos para descubrir qué elementos existen fuera de su ámbito.
## Lo que necesitas saber
***
* **Los permisos y el ámbito deben coincidir los dos.** Un socio alcanza solo lo que ambos permiten. No se pueden guardar permisos sin ámbito en un producto con una restricción obligatoria.
* **La suspensión y el fin de la ventana de validez se aplican al instante.** La siguiente solicitud del socio se rechaza, incluso con un token que ya tiene. Un socio suspendido tampoco puede obtener tokens nuevos.
* **Cualquier otro cambio se aplica desde la siguiente solicitud.** Eso incluye permisos nuevos, un ámbito más estrecho y una nueva lista de IP permitidas.
* **Un socio nunca recibe más de lo que tiene tu tenant.** El techo es lo que tiene el rol de editor del producto en tu tenant. Si ese rol pierde un permiso después, el socio también lo pierde.
* **Access Manager no verifica que los IDs del ámbito existan en el producto.** Guarda los IDs que ingresas. Cópialos de la propia API o de Console del producto.
* **Un producto que se muestra como "isn't ready for partners yet" todavía no publicó su lista de restricciones.** No puedes dar a un socio acceso a ese producto hasta que la publique.
* **Una solicitud que deja fuera un elemento que el ámbito restringe se rechaza.** Por ejemplo, un socio restringido a algunos ledgers no puede listar todos los ledgers de la organización.
* **Un socio con aplicaciones no se puede eliminar.** Elimina primero sus aplicaciones. Para pausar un socio, suspéndelo. La suspensión es reversible; la eliminación no.
* **La lista de IP permitidas propia de un socio reemplaza la lista de tu tenant.** No se suma a ella. Una dirección que está solo en la lista de tu tenant no funciona para ese socio. La lista del socio se aplica incluso cuando la lista de tu tenant está apagada.
## Productos que aceptan socios
***
Cada producto declara, en su manifiesto de permisos, qué restricciones acepta: por ejemplo organización, ledger, cuenta, portafolio o segmento. Hoy Midaz (el ledger) y Tracer aceptan socios. Midaz exige una organización para cada socio y acepta restricciones opcionales en ledgers, cuentas, alias de cuenta, activos, portafolios, segmentos, titulares y otros elementos. Tracer acepta restricciones opcionales en reglas, límites, validaciones de transacciones, cuentas, portafolios, segmentos y comercios.
## Próximos pasos
***
Crea un socio paso a paso, emite sus credenciales, suspéndelo o elimínalo.
Las operaciones de socios, sus campos, ejemplos y códigos de error.
La lista del tenant que usa un socio sin lista propia.
Todos los códigos que puede devolver Access Manager.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.