Skip to main content

​
APIs de Lerian

Esta sección responde preguntas comunes sobre las APIs de Lerian. Cubre comportamiento general, configuración y mejores prácticas en todos los servicios.
Sí. El máximo por defecto es 100 registros por página. Este límite mantiene el rendimiento consistente y controla el volumen de datos en cada solicitud. Para aumentarlo, configura la variable de entorno MAX_PAGINATION_LIMIT en tu configuración de despliegue. La API acepta tamaños de página más grandes después de que reinicies la aplicación.Importante: Un tamaño de página mayor puede ralentizar los tiempos de respuesta, especialmente con grandes conjuntos de datos. Prueba en staging antes de cambiar producción.

​
Multi-tenancy y SaaS

Estas preguntas cubren el aislamiento de datos, el alcance de tenant y cómo funciona multi-tenancy en los despliegues de Lerian.
Sí. Cada tenant opera en una base de datos separada. La plataforma resuelve tu tenant a partir del JWT en cada solicitud y la dirige a tu base de datos aislada. No hay forma de acceder a los datos de otro tenant a través de la API. Más información sobre multi-tenancy.
No. El JWT access token que recibes durante la autenticación lleva el contexto de tu tenant. La plataforma lo resuelve automáticamente. No necesitas incluir un identificador de tenant en headers ni en el cuerpo de la solicitud.
Sí. Un tenant puede contener múltiples Organizaciones. Cada Organización tiene sus propios Ledgers, cuentas y transacciones. La plataforma vincula todas a tu tenant automáticamente.
No. La superficie de API es idéntica: mismos endpoints, mismos payloads, mismas respuestas. Solo una cosa difiere. SaaS requiere autenticación en cada solicitud, y tu token delimita todas las operaciones a tu tenant.

​
Midaz

Estas preguntas cubren Organizaciones, Ledgers, Cuentas, Transacciones y más en Midaz.

​
Organizaciones

No. Cada Organización opera de forma independiente y no se comunica con otras.
No. Cada licencia se vincula a una Organización. Para dar soporte a múltiples Organizaciones, adquiere una licencia separada para cada una. La misma regla aplica a los Plugins.
Sí. Una Organización puede tener más de un Plugin.
Sí. Una Organización puede gestionar múltiples Ledgers.
Puedes crear una Organización Padre y una Organización Hija. Cada Organización mantiene su propio Ledger y opera de forma independiente. Las transacciones no pueden mover valor directamente entre Ledgers. Orquesta la transferencia con estos pasos:
1
En el Ledger de origen, crea una transacción de la cuenta original (source) a la cuenta externa del activo (distribute). Esto elimina el valor del Ledger de origen.
2
En el Ledger de destino, crea una segunda transacción. El source es ahora la cuenta externa del activo, y el destino es la cuenta receptora (distribute).
Este patrón mueve valor entre Ledgers de diferentes Organizaciones de forma controlada.

​
Ledgers

No. Los Ledgers no se comunican directamente. Las transferencias entre Ledgers requieren orquestación.
Debes orquestar el proceso y mover el monto a través de una Cuenta Externa. Esto involucra dos pasos:
1
Ledger A -> Cuenta Externa.
2
Cuenta Externa -> Ledger B.
No. Un único Ledger puede soportar múltiples Plugins. Por ejemplo, un Ledger puede manejar tanto Plugins de Exchange como de Pix.

​
Activos

No. Cada Activo se vincula a una única Cuenta. Cada Activo también se vincula a una Cuenta Externa. Midaz crea esa Cuenta Externa automáticamente cuando creas el Activo.
Midaz admite varios tipos de Activos:
  • currency: Monedas fiduciarias tradicionales como BRL, USD y EUR.
  • fiat: Un tipo alternativo para monedas fiduciarias; como currency, el código del Activo debe seguir la norma ISO 4217.
  • crypto: Activos digitales como BTC, ETH y otras criptomonedas.
  • commodities: Bienes tangibles como oro, soja y petróleo.
  • others: Activos personalizados, incluyendo puntos de lealtad y valores tokenizados.

​
Portafolios

Un Portafolio agrupa cuentas que pertenecen a la misma entidad (CPF/CNPJ). Por ejemplo, un CPF con dos valores diferentes de segment_id tiene dos valores de account_id correspondientes. Creas un Portafolio para ese CPF para vincular ambas cuentas bajo una única estructura. Esto facilita encontrar y gestionar las cuentas relacionadas.

​
Cuentas

No. Cada Cuenta se vincula a un único Activo. No puedes cambiar este vínculo.
Una Cuenta Externa recibe fondos desde fuera del Ledger. Trae dinero al sistema.
Midaz crea una Cuenta Externa automáticamente cuando creas un Activo. Esta Cuenta Externa respalda todas las transacciones que entran y salen del Ledger.
No. Cada cuenta (account_id) se vincula solo a un Segmento (segment_id).
No. Puedes crear tantas Cuentas como necesites. Midaz no impone ningún límite en el número de Cuentas.
El proceso de recarga de saldo funciona así:
  1. Cuando creas un Activo (por ejemplo, BRL) en el Ledger de Midaz, Midaz también crea una Cuenta Externa para ese Activo.
  2. Esta Cuenta Externa refleja los saldos que la institución mantiene fuera de Midaz. Esos saldos pueden estar en una cuenta PI, una cuenta de liquidación, una cuenta de reserva, o una cuenta bancaria tradicional o de pago.
  3. Para depositar fondos desde fuera del Ledger de Midaz en una cuenta de usuario, sigue estos pasos:
    • Crea una transacción con la Cuenta Externa como origen y las cuentas objetivo como destino.
    • Midaz debita la Cuenta Externa por el monto (por lo que se vuelve negativa) y acredita las cuentas de destino según los valores en el payload de la transacción.

​
Transacciones

Una Transacción debe tener al menos dos Operaciones. Por ejemplo, una transferencia de R$ 100 de la Cuenta A a la Cuenta B tiene dos operaciones:
  • Operación 1: Debitar R$ 100 de la Cuenta A.
  • Operación 2: Acreditar R$ 100 a la Cuenta B.
Lerian ofrece a los clientes varias formas de acceder a los recibos de transacciones:
  1. Vía APIs — Recupera los datos de la transacción a través de las APIs y luego genera un recibo visual en el formato que elijas.
  2. Con el Reporter — Extrae los datos de la transacción y crea recibos visuales personalizados.
  3. A través del Console — Accede a los datos de la transacción directamente en Lerian Console.

​
Entidades

La Entidad (entity_id) acepta IDs externos. Midaz no impone ninguna validación en este campo. Puedes usar los IDs que ya existen en tu base de datos e integrarlos en tu sistema.

​
Idempotencia

Midaz trata la solicitud como nueva cada vez. Los reintentos pueden entonces crear operaciones duplicadas.
No. Limita cada clave a una única operación y endpoint.
Midaz usa solo el TTL de la primera solicitud. Un cambio posterior no tiene efecto.
Sí. Para una solicitud completada, Midaz devuelve el mismo resultado que almacenó de la primera solicitud. También establece el header X-Idempotency-Replayed en true.
El TTL predeterminado es de 300 segundos (5 minutos). Envía el header X-TTL para definir un valor personalizado en segundos.

​
Contabilidad en Midaz

Midaz te permite reflejar el Plan de Cuentas oficial de tu organización en la plataforma. Configuras dos características principales:
  • Tipos de Cuenta — Crea las categorías lógicas de tu plan, como Activos, Pasivos, Ingresos y Gastos. Asígnalas a cuentas en tu Ledger. Cuando habilitas la función Tipos de Cuenta, el campo type en la API de Cuentas se vuelve obligatorio y debe coincidir con un valor registrado.
  • Rutas Contables — Usa Rutas de Operación para validar cada pierna de una transacción. Por ejemplo, un débito debe provenir de una cuenta de tipo user_wallet. Usa Rutas Contables (el recurso transactionRoute en la API) para definir patrones completos de transacción que coincidan con tu lógica contable.
Los Tipos de Cuenta y las Rutas Contables juntos hacen cumplir tus reglas contables a nivel de Ledger. Midaz valida y categoriza cada transacción según tu Plan de Cuentas. No codificas reglas en tu lógica de negocio.

​
Plugins

Los plugins extienden Midaz con integración y orquestación de procesos. Proporcionan abstracciones para que puedas enfocarte en tu modelo de negocio en lugar de lógica del sistema fuera de tu dominio. Las preguntas siguientes cubren cómo funcionan los plugins, cómo los despliegas y las opciones disponibles.
Los plugins son tecnologías que se integran en el Ledger de Midaz. Simplifican la integración y orquestación de procesos. Proporcionan abstracciones para que los clientes se enfoquen en su modelo de negocio. Los clientes no construyen ni gestionan lógica del sistema fuera de su dominio.
No. Los plugins operan solo con Midaz. Proporcionan abstracciones específicas y orquestan transacciones basándose en la estructura del Ledger.
Después de que contratas un plugin, Lerian lo proporciona e instala en tu infraestructura (modelo on-premise), junto a tu instancia de Midaz. Las aplicaciones se conectan a cada plugin según su función.
Lerian proporciona dos tipos de plugins, agrupados por origen:
  • Plugins Nativos: Lerian desarrolla e integra estos plugins en el Ledger de Midaz. Lerian brinda soporte completo para ellos.
  • Plugins de Marketplace: Los socios de Lerian crean estos plugins para nichos de mercado específicos. Lerian ayuda a integrarlos en Midaz. Los socios los ofrecen y les dan soporte directamente.

​
Fees Engine

Estas preguntas cubren el Fees Engine. Fees Engine es una capacidad con licencia de Midaz que se ejecuta dentro del proceso unificado del ledger.

​
Conceptos Generales

Fees Engine forma parte de Midaz. Se ejecuta en el proceso del ledger de Midaz para calcular tarifas de transacciones financieras. Configúralo y despliégalo con Midaz. Más información en la descripción general del Fees Engine. Opera en tres dominios principales:
  • Paquetes de Tarifas (/v1/packages): define las reglas de cobro por transacción (tarifa fija, porcentual, o el mayor entre ambos).
  • Billing Packages (/v1/billing-packages): define cobros periódicos por volumen de transacciones o por mantenimiento de cuentas.
  • Cálculo y Estimación (/v1/fees y /v1/estimates): endpoints para calcular tarifas en tiempo real o simular antes de confirmar.
Fees Engine se ejecuta dentro del proceso del ledger de Midaz. Cuando se aplica un paquete de tarifas configurado, Midaz incorpora sus cálculos de tarifas en la transacción. Usa casos de uso de consulta del ledger en lugar de una conexión HTTP externa a Midaz.
Cada solicitud requiere el header X-Organization-Id con el ID de tu organización en Midaz. Este header delimita la solicitud a una organización. Es específico del Fees Engine, no un identificador de tenant. La plataforma sigue resolviendo el contexto de tu tenant automáticamente desde el JWT. Cuando el plugin de autenticación está activo, también envías un Bearer token en el header Authorization.
El Fees Engine usa MongoDB para almacenamiento. Las eliminaciones siguen el patrón de soft-delete. El Fees Engine no elimina los registros físicamente. En su lugar, los marca con deletedAt. Un registro eliminado no aparece en los listados, pero aún puedes auditarlo.
Necesitas Midaz v3.6.0 o superior. El Fees Engine depende de APIs del módulo Transaction que Midaz añadió en la v3.6.0. Las versiones anteriores de Midaz no funcionan con el Fees Engine.

​
Paquetes de Tarifas

Un Paquete de Tarifas (Package) es un conjunto de reglas de cobro bajo un feeGroupLabel. Cada paquete se vincula a una Organización + Ledger y, opcionalmente, a un Segment. Un paquete puede contener varias tarifas (objetos Fee), cada una con su propia lógica de cálculo. Más información sobre Paquetes de Tarifas.
Envía un POST /v1/packages con el siguiente cuerpo. Consulta la referencia de la API Create Package para detalles completos.
Sí. Configura el campo enable en false cuando creas o actualizas el paquete. El Fees Engine omite un paquete desactivado durante el cálculo de tarifas, incluso cuando el contexto de la transacción coincide con su alcance.
El Fees Engine aplica el paquete solo a transacciones cuyo valor esté dentro del rango [minimumAmount, maximumAmount]. Si el valor de la transacción queda fuera de este rango, el Fees Engine ignora el paquete.Ejemplo: Un paquete con minimumAmount: 100 y maximumAmount: 5000 cobra tarifas solo en transacciones entre 100 y 5.000.
Si no defines maximumAmount, el paquete puede aplicarse sin límite superior. Verifica las reglas de validación de tu versión.
Sí. Configura el campo transactionRoute en el paquete. El Fees Engine considera entonces el paquete solo para transacciones con esa ruta, como "PIX", "TED" o "BOLETO".
Son aliases de cuentas que el paquete exime de tarifas. Si el remitente o destinatario de la transacción es una cuenta en waivedAccounts, el Fees Engine no aplica las tarifas del paquete a ella.
Este paquete no cobra ninguna transacción que provenga de estas cuentas o se destine a ellas.
Sí. Los endpoints de listado (GET /v1/packages, GET /v1/billing-packages) soportan los parámetros de query limit y page para paginación.

​
Modelos de Cálculo

El campo applicationRule dentro de calculationModel define cómo el Fees Engine calcula la tarifa. Consulta Modelos de Cálculo para detalles completos. Hay tres opciones:
Usa exactamente 1 cálculo de tipo flat:
Esto cobra 5,00 fijos, independientemente del valor de la transacción.
Usa exactamente 1 cálculo de tipo percentage:
Esto cobra 2,5% sobre el valor de referencia de la transacción.
El maxBetweenTypes requiere 2 o más cálculos que combinan flat y percentage. El Fees Engine calcula ambos y aplica el mayor resultado.Ejemplo: Tarifa mínima de 3,00 o 1% del valor — el que sea mayor:
Para una transacción de 200: 1% = 2,00 vs. 3,00 fijo → cobra 3,00. Para una transacción de 500: 1% = 5,00 vs. 3,00 fijo → cobra 5,00.
Sí. Puedes incluir cualquier combinación de flat y percentage. El Fees Engine evalúa todos y aplica el mayor. Ten en cuenta que flatFee y percentual requieren exactamente 1 cálculo. Solo maxBetweenTypes acepta 2 o más.

​
Campos Importantes

El referenceAmount define sobre qué valor el Fees Engine calcula la tarifa:
  • originalAmount: el valor original de la transacción, antes de cualquier tarifa.
  • afterFeesAmount: el valor de la transacción después de que se apliquen las tarifas de mayor prioridad.
La tarifa con priority: 1 se ejecuta primero, por lo que debe usar originalAmount. No hay tarifas anteriores que considerar.
Cuando isDeductibleFrom: true, el Fees Engine deduce la tarifa del monto que envía el remitente. El destinatario recibe el monto descontado, y el remitente paga extra para cubrir el cargo.Cuando false, el Fees Engine cobra la tarifa por separado. El remitente envía el monto completo, y el Fees Engine debita la tarifa aparte.Restricciones:
  • isDeductibleFrom: true requiere referenceAmount: originalAmount
  • Si el tipo es percentage: el valor no puede exceder 100
  • Si el tipo es flat: el valor no puede exceder el minimumAmount del paquete
El priority define el orden de ejecución de las tarifas dentro de un paquete. El Fees Engine ejecuta primero los valores menores.
  • priority: 1 → se ejecuta primero (obligatoriamente usa originalAmount)
  • priority: 2 → se ejecuta después, puede usar afterFeesAmount
Usa prioridades para encadenar tarifas. Por ejemplo, ejecuta una tarifa administrativa sobre el valor original. Luego ejecuta una tarifa de impuesto sobre el valor posterior a la tarifa administrativa.
Es el alias de la cuenta en el ledger que recibe los ingresos de la tarifa. Cada tarifa puede tener un creditAccount diferente. Esto ayuda cuando diferentes tarifas pertenecen a centros de costo distintos.
Estos campos definen las rutas de las patas contables que genera el cobro de la tarifa. Son opcionales. Te permiten rastrear el origen y destino de los movimientos de tarifa en el ledger.

​
Billing Packages

Los Billing Packages son paquetes de cobro periódico, independientes del cálculo de tarifas por transacción. Consulta ejemplos de Billing Packages para casos de uso. Existen dos tipos:
  • volume: cobra según la cantidad de transacciones en un período, con precios escalonados (tiers).
  • maintenance: cobra una tarifa fija por cuenta en un alcance determinado.
Usa el billing de volumen para cobrar a clientes según el número de transacciones procesadas. Es un modelo común en plataformas de pago con precios por volumen. Define escalones de precio (tiers) que se aplican a medida que el volumen crece.
El último tier debe ser ilimitado (sin maxQuantity). No puede haber brechas ni superposiciones entre tiers.
Usa el billing de mantenimiento para cobrar una tarifa fija periódica por cuenta. Por ejemplo, cobra una mensualidad por cuenta activa. Especifica el alcance (segmentId, portfolioId o aliases) y el valor de la tarifa.
accountTarget debe tener exactamente uno de los tres campos: segmentId, portfolioId o aliases (máximo 100 aliases).
Los tiers definen el precio unitario por escalón a medida que el volumen aumenta. Las reglas son:
  1. Deben ser contiguos — sin brechas entre escalones (minQuantity del siguiente = maxQuantity del anterior + 1).
  2. No pueden tener superposición.
  3. El último tier debe ser ilimitado (sin maxQuantity).
Ejemplo de tiers correctos:
Es una franquicia gratuita. El Fees Engine no cobra un número determinado de transacciones antes de que se apliquen los tiers. Esto ayuda a los modelos de precios con un volumen mínimo incluido.Ejemplo: freeQuota: 100 significa que el Fees Engine no cobra las primeras 100 transacciones del período.
Son escalones de descuento para el billing de volumen. Reducen el valor cobrado según criterios adicionales. Complementan la lógica de los tiers principales.
Define cómo el Fees Engine cuenta las transacciones:
  • perRoute: cuenta transacciones por ruta (ej: total de PIX aprobados).
  • perAccount: cuenta transacciones por cuenta individualmente.

​
Cálculo y Estimación de Tarifas

El endpoint recibe los datos de la transacción. El sistema busca automáticamente los paquetes aplicables. Considera:
  • ledgerId — obligatorio
  • segmentId — opcional
  • transactionRoute — opcional
  • Valor de la transacción — comparado con minimumAmount/maximumAmount del paquete
El Fees Engine calcula y retorna las tarifas de todos los paquetes correspondientes.
El endpoint /v1/estimates simula la tarifa de un paquete específico (packageId). No necesitas una transacción real. Funciona bien para:
  • Mostrar el costo estimado al usuario antes de la confirmación.
  • Probar configuraciones de paquetes recién creados.
  • Construir simuladores de tarifas en tu producto.
Sí. El /v1/estimates es un endpoint de solo lectura. No altera estado ni registra transacciones. Es seguro usarlo en flujos de UX para mostrar el costo antes de la confirmación.
Después de que configures los Billing Packages, llama a este endpoint:
Este endpoint procesa las reglas configuradas y genera los cobros para el período. Consulta la referencia de la API Calculate Billing.

​
Errores Comunes

La tarifa con priority: 1 debe tener referenceAmount: "originalAmount". Es la primera tarifa en ejecutarse, por lo que no hay tarifas anteriores sobre las cuales basar el cálculo.Corrección:
Las tarifas con isDeductibleFrom: true solo pueden usar referenceAmount: "originalAmount". Actualiza el campo:
Cuando isDeductibleFrom: true y el tipo es flat, el valor de la tarifa no puede exceder el minimumAmount del paquete. Esto evita una tarifa mayor que el valor mínimo de la transacción.Ejemplo: Si minimumAmount: 100, la tarifa flat no puede exceder 100.
Este error ocurre cuando isDeductibleFrom: true, el tipo es percentage y el valor supera 100. Una tarifa porcentual deducible del 100% anularía el valor de la transacción. Los valores superiores a 100 son inválidos.
Los tiers de billing de volumen deben cubrir todos los rangos sin brechas. Verifica que el minQuantity de cada tier sea exactamente maxQuantity + 1 del tier anterior.
El último tier en el billing de volumen debe ser sin límite superior (sin maxQuantity). Esto mantiene un precio en las transacciones por encima del mayor rango definido.
En el billing de tipo maintenance, el campo accountTarget acepta solo una de las tres opciones. No combines campos:
Sí. El campo aliases acepta un máximo de 100 aliases por Billing Package de tipo maintenance.
El applicationRule: "flatFee" acepta exactamente 1 cálculo, y debe ser de tipo flat. No uses percentage con flatFee.
Como el flatFee, el applicationRule: "percentual" acepta exactamente 1 cálculo de tipo percentage.
El maxBetweenTypes requiere al menos 2 cálculos para funcionar — necesita valores para comparar. Proporciona al menos un flat y un percentage.
Lista de verificación — consulta también Mejores Prácticas:
  • enable: ¿el paquete está activo (enable: true)?
  • ledgerId: ¿el paquete está vinculado al ledger correcto?
  • minimumAmount / maximumAmount: ¿el valor de la transacción está dentro del rango?
  • transactionRoute: si el paquete tiene transactionRoute, ¿la transacción usa la misma ruta?
  • segmentId: si el paquete está vinculado a un segmento específico, ¿la cuenta pertenece a él?
  • waivedAccounts: ¿la cuenta está listada como exenta?
El Fees Engine hace soft-delete de los registros. Los marca con deletedAt y no los elimina de la base de datos. La API no expone endpoints de restauración por defecto. Contacta al equipo de Lerian si necesitas recuperar un registro eliminado. Para la lista completa de códigos de error, consulta la referencia de Códigos de Error.