Saltar al contenido principal

​
APIs de Lerian

Esta sección responde preguntas frecuentes sobre las APIs de Lerian, cubriendo comportamiento general, configuración y mejores prácticas en todos los servicios.
Sí. Por defecto, el número máximo de registros por página es 100. Este límite garantiza un rendimiento consistente y ayuda a gestionar el volumen de datos transferidos en cada solicitud. Sin embargo, puedes aumentar este valor configurando la variable de entorno MAX_PAGINATION_LIMIT en tu configuración de despliegue. Una vez actualizada y reiniciada la aplicación, la API aceptará tamaños de página más grandes.Importante: Aumentar el tamaño de página puede afectar los tiempos de respuesta, especialmente en entornos que manejan grandes conjuntos de datos. Siempre prueba exhaustivamente en staging antes de aplicar cambios en producción.

​
Multi-tenancy y SaaS

Preguntas frecuentes sobre aislamiento de datos, 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 contexto de tu tenant está incluido en el JWT access token que recibes durante la autenticación. La plataforma lo resuelve automáticamente — no necesitas incluir ningún identificador de tenant en headers ni en el cuerpo de la solicitud.
Sí. Un tenant puede contener múltiples Organizaciones, cada una con sus propios Ledgers, cuentas y transacciones. Todas están vinculadas a tu tenant automáticamente.
No. La superficie de API es idéntica — mismos endpoints, mismos payloads, mismas respuestas. La única diferencia es que SaaS requiere autenticación en cada solicitud, y tu token delimita automáticamente todas las operaciones a tu tenant.

​
Midaz

Aquí encontrarás respuestas a preguntas comunes sobre 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 está vinculada a una Organización específica. Si necesitas soporte para múltiples Organizaciones, debes adquirir licencias separadas para cada una. La misma regla aplica para los Plugins.
Sí, una Organización puede tener más de un Plugin asociado.
Sí, una Organización puede gestionar múltiples Ledgers.
Aunque puedes crear una Organización Padre y una Organización Hija, cada Organización mantiene su propio Ledger, operando independientemente. Dado que las transacciones no pueden mover valor directamente entre Ledgers, necesitas orquestar la transferencia con los siguientes pasos:
1
Inicia una transacción en el Ledger de origen, transfiriendo el monto de la cuenta original (source) a la cuenta externa del activo (distribute). Esto elimina el valor del Ledger original.
2
Crea una segunda transacción en el Ledger de destino, donde el source es ahora la cuenta externa del activo, y el monto se asigna a la cuenta receptora (distribute).
Este enfoque garantiza transferencias de valor fluidas y controladas entre Ledgers de diferentes organizaciones.

​
Ledgers

No, los Ledgers no se comunican directamente. Las transferencias entre Ledgers requieren orquestación.
Debes orquestar el proceso y transferir el monto a una Cuenta Externa. Típicamente, 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 simultáneamente.

​
Activos

No, cada Activo está vinculado a una única Cuenta. Sin embargo, cada Activo también estará vinculado a una Cuenta Externa que se crea automáticamente cuando se crea el Activo.
Midaz está construido para flexibilidad, soportando una amplia gama de Activos:
  • currency: Monedas fiduciarias tradicionales como BRL, USD y EUR.
  • 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, si un único CPF tiene dos valores diferentes de segment_id, también tendrá dos valores correspondientes de account_id. Para simplificar la recuperación, se crea un Portafolio para ese CPF, vinculando ambas cuentas bajo una única estructura. Esto garantiza un acceso y gestión más fáciles de cuentas relacionadas.

​
Cuentas

No, cada Cuenta está asociada con un único Activo, y esta asociación no puede cambiarse.
Una Cuenta Externa se usa para recibir fondos desde fuera del Ledger, efectivamente trayendo dinero al sistema.
Midaz configura automáticamente una Cuenta Externa cuando creas un Activo, garantizando respaldo continuo para todas las transacciones que fluyen dentro y fuera del Ledger.
No. Cada cuenta (account_id) puede estar vinculada solo a un Segmento (segment_id).
No. Puedes crear tantas Cuentas como necesite tu configuración. Sin límites, sin restricciones—solo la flexibilidad para escalar a tu manera.
Para entender el proceso de recarga de saldo, consideremos los siguientes puntos:
  1. En el Ledger de Midaz, cuando se crea un Activo (por ejemplo, BRL), también se genera una Cuenta Externa asociada con ese activo.
  2. Esta Cuenta Externa actúa como puerta de enlace entre el ecosistema de Lerian y el mundo externo. En otras palabras, sirve como espejo de los saldos mantenidos por la institución en su cuenta PI, cuenta de liquidación, cuenta de reserva, o incluso una cuenta bancaria tradicional o de pago que mantiene los fondos reales.
  3. Para depositar fondos en una cuenta de usuario con un Activo específico proveniente de fuera del Ledger de Midaz, el proceso es el siguiente:
    • Inicia una transacción donde la fuente es la Cuenta Externa y el destino es la(s) cuenta(s) objetivo.
    • Como resultado, la Cuenta Externa se debitará por el monto transferido (volviéndose negativa), mientras que la(s) cuenta(s) destino se acreditarán en consecuencia, según los valores proporcionados en la carga útil de la transacción.

​
Transacciones

Una Transacción debe tener al menos dos Operaciones. Por ejemplo, transferir R$ 100 de la Cuenta A a la Cuenta B consiste en:
  • Operación 1: Debitar R$ 100 de la Cuenta A.
  • Operación 2: Acreditar R$ 100 a la Cuenta B.
Lerian proporciona a los clientes múltiples opciones para acceder a recibos de transacciones:
  1. Vía APIs – Recupera datos de transacciones a través de nuestras APIs, permitiéndote generar un recibo visual en el formato de tu elección.
  2. Usando el Reporter – Extrae datos de transacciones y crea recibos visuales personalizados.
  3. A través de Lerian Console – Accede a información de transacciones directamente desde Lerian Console.

​
Entidades

Actualmente, la Entidad (entity_id) está abierta para IDs externos, sin validación impuesta por Midaz. Esto significa que puedes usar los IDs que ya existen en tu base de datos, integrándolos sin problemas en tu sistema.

​
Idempotencia

Midaz trata la solicitud como nueva cada vez. Esto significa que los reintentos pueden resultar en operaciones duplicadas.
No. Las claves deben estar limitadas a una única operación y endpoint.
Solo se usa el TTL de la primera solicitud. Cambiarlo posteriormente no tiene efecto.
Sí. Midaz reproduce la respuesta completa, incluyendo encabezados y cuerpo, para solicitudes completadas.
La ventana predeterminada es 300 segundos (5 minutos), pero puedes personalizarla hasta tu límite permitido por endpoint.

​
Contabilidad en Midaz

R: Midaz te permite reflejar el Plan de Cuentas oficial de tu organización directamente en la plataforma configurando dos características principales:
  • Tipos de Cuenta – Crea las categorías lógicas de tu plan (por ejemplo, Activos, Pasivos, Ingresos, Gastos) y asígnalas a cuentas en tu Ledger. Cuando la función de Tipos de Cuenta está habilitada, el campo tipo en la API de Cuentas se vuelve obligatorio y debe coincidir con uno de los valores que has registrado.
  • Enrutamiento de Transacciones – Usa Rutas de Operación para validar cada “pierna” de una transacción (por ejemplo, el débito debe provenir de un tipo de cuenta user_wallet) y Rutas de Transacción para definir patrones completos de transacción que se alineen con tu lógica contable.
Al combinar Tipos de Cuenta y Enrutamiento de Transacciones, puedes hacer cumplir tus reglas contables a nivel de Ledger — garantizando que cada transacción sea validada y categorizada según tu Plan de Cuentas, sin codificar reglas en tu lógica de negocio.

​
Plugins

Los plugins extienden las capacidades de Midaz, habilitando integración fluida y orquestación de procesos. Diseñados para eliminar complejidad, proporcionan abstracciones poderosas que te permiten enfocarte en tu modelo de negocio mientras garantizan eficiencia y escalabilidad. Explora las preguntas más comunes sobre cómo funcionan los plugins, su despliegue y las opciones disponibles para mejorar tus operaciones.
Los plugins son tecnologías integradas en el Ledger de Midaz, diseñadas para simplificar la integración y orquestación de procesos. Proporcionan abstracciones que permiten a los clientes enfocarse en su modelo de negocio sin necesidad de construir o gestionar lógica esencial del sistema que cae fuera de su dominio.
No. Los plugins están diseñados para operar exclusivamente con Midaz. Proporcionan abstracciones específicas y orquestan transacciones basándose en la estructura del Ledger, garantizando integración precisa y eficiente.
Una vez contratados, los plugins se proporcionan e instalan dentro de la infraestructura del cliente (modelo on-premise), junto con su instancia de Midaz. Las aplicaciones se conectan según la funcionalidad específica de cada plugin.
Lerian proporciona dos tipos de plugins, categorizados por su origen:
  • Plugins Nativos: Desarrollados e integrados completamente en el Ledger de Midaz por Lerian, estos plugins garantizan soporte completo e integración fluida con la plataforma.
  • Plugins de Marketplace: Creados por socios de Lerian para servir nichos de mercado específicos, estos plugins están disponibles en el marketplace. Lerian facilita su integración en Midaz, pero su oferta y soporte son gestionados directamente por los socios respectivos.

​
Plugin Fees

Preguntas frecuentes sobre el Plugin Fees — el servicio de Lerian responsable de calcular y cobrar tarifas sobre transacciones financieras.

​
Conceptos Generales

El Plugin Fees es un servicio de Lerian responsable de calcular y cobrar tarifas sobre transacciones financieras. Más información en la descripción general del Plugin Fees. 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.
El Plugin Fees es un módulo opcional que se integra con Midaz (el ledger de Lerian). Intercepta transacciones y, según las reglas configuradas, determina cuánto debe cobrarse — y a quién. Los ingresos por tarifas se acreditan directamente en cuentas del ledger configuradas por el cliente.
Todas las solicitudes requieren el header X-Organization-Id con el ID de tu organización en Midaz. Este es un header de alcance de organización específico del Plugin Fees, no un identificador de tenant — el contexto de tu tenant se resuelve automáticamente desde el JWT. Cuando el plugin de autenticación está activo, también se requiere un Bearer token en el header Authorization.
X-Organization-Id: <tu-organization-id>
Authorization: Bearer <tu-token>
El Plugin Fees usa MongoDB como backend de almacenamiento. Las eliminaciones siguen el patrón de soft-delete — los registros no se eliminan físicamente, solo se marcan con deletedAt. Esto significa que los registros “eliminados” no aparecen en los listados, pero pueden ser auditados.
Midaz v3.6.0 o superior. La versión actual del Plugin Fees depende de APIs del módulo Transaction que solo están disponibles a partir de la v3.6.0. Versiones anteriores de Midaz no son compatibles.

​
Paquetes de Tarifas

Un Paquete de Tarifas (Package) es un conjunto de reglas de cobro agrupadas bajo un feeGroupLabel. Cada paquete está vinculado a una Organización + Ledger y, opcionalmente, a un Segment. Un paquete puede contener múltiples tarifas individuales (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.
{
  "feeGroupLabel": "Tarifas Cuenta Digital",
  "ledgerId": "ldg_abc123",
  "segmentId": "seg_xyz456",
  "minimumAmount": "100.00",
  "maximumAmount": "50000.00",
  "transactionRoute": "PIX",
  "enable": true,
  "waivedAccounts": ["cuenta-exenta-1", "cuenta-exenta-2"],
  "fees": {
    "tarifa_admin": {
      "feeLabel": "Tarifa Administrativa",
      "calculationModel": {
        "applicationRule": "percentual",
        "calculations": [
          { "type": "percentage", "value": "1.50" }
        ]
      },
      "referenceAmount": "originalAmount",
      "priority": 1,
      "isDeductibleFrom": true,
      "creditAccount": "cuenta-ingresos-tarifas"
    }
  }
}
Sí. Usa el campo enable: false al crear o actualizar el paquete. Un paquete desactivado no se considera en el cálculo de tarifas, incluso si el contexto de la transacción coincide con tu alcance.
El paquete solo se aplica a transacciones cuyo valor esté dentro del rango [minimumAmount, maximumAmount]. Si la transacción no encaja en este rango, el paquete se ignora.Ejemplo: Un paquete con minimumAmount: 100 y maximumAmount: 5000 solo cobrará tarifas en transacciones entre 100 y 5.000.
Si maximumAmount no está definido, el paquete puede aplicarse sin límite superior — verifica las reglas de validación de tu versión.
Sí. Usa el campo transactionRoute en el paquete. Cuando está definido, el paquete solo se considerará en transacciones con esa ruta específica (ej: "PIX", "TED", "BOLETO").
Son aliases de cuentas exentas de tarifas dentro de ese paquete. Si el remitente o destinatario de la transacción es una cuenta listada en waivedAccounts, las tarifas del paquete no se aplican.
"waivedAccounts": ["cuenta-vip", "cuenta-empleado"]
Cualquier transacción originada o destinada a estas cuentas no será tarifada por este paquete.
Sí. Los endpoints de listado (GET /v1/packages, GET /v1/billing-packages) soportan los parámetros de query limit y page para paginación.
GET /v1/packages?limit=20&page=2

​
Modelos de Cálculo

El campo applicationRule dentro de calculationModel define cómo se calcula la tarifa. Consulta Modelos de Cálculo para detalles completos. Hay tres opciones:
ReglaDescripción
flatFeeTarifa fija en valor absoluto
percentualTarifa porcentual sobre el valor de referencia
maxBetweenTypesCalcula flat y porcentual; aplica el mayor resultado
Usa exactamente 1 cálculo de tipo flat:
"calculationModel": {
  "applicationRule": "flatFee",
  "calculations": [
    { "type": "flat", "value": "5.00" }
  ]
}
Esto cobra 5,00 fijos, independientemente del valor de la transacción.
Usa exactamente 1 cálculo de tipo percentage:
"calculationModel": {
  "applicationRule": "percentual",
  "calculations": [
    { "type": "percentage", "value": "2.50" }
  ]
}
Esto cobra 2,5% sobre el valor de referencia de la transacción.
El maxBetweenTypes requiere 2 o más cálculos (combinando flat y percentage). El sistema calcula ambos y aplica el mayor valor resultante.Ejemplo: Tarifa mínima de 3,00 o 1% del valor — el que sea mayor:
"calculationModel": {
  "applicationRule": "maxBetweenTypes",
  "calculations": [
    { "type": "flat", "value": "3.00" },
    { "type": "percentage", "value": "1.00" }
  ]
}
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í. Puede incluir cualquier combinación de flat y percentage — el sistema evalúa todos y aplica el mayor. Sin embargo, flatFee y percentual requieren exactamente 1 cálculo; solo maxBetweenTypes acepta 2 o más.

​
Campos Importantes

El referenceAmount define sobre qué valor se calcula la tarifa:
  • originalAmount: valor original de la transacción, antes de que se aplique cualquier tarifa.
  • afterFeesAmount: valor de la transacción después de que las tarifas de mayor prioridad ya se hayan aplicado.
La tarifa con priority: 1 (la primera en ejecutarse) debe usar originalAmount. No hay tarifas anteriores que considerar.
Cuando isDeductibleFrom: true, la tarifa se deduce del monto enviado por el remitente. El destinatario recibe el monto ya descontado, y el remitente paga extra para cubrir el cargo.Cuando false, la tarifa se cobra por separado (el remitente envía el monto completo y la tarifa se debita 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. Valores menores se ejecutan primero.
  • priority: 1 → se ejecuta primero (obligatoriamente usa originalAmount)
  • priority: 2 → se ejecuta después, puede usar afterFeesAmount
Usa prioridades para crear encadenamiento de tarifas — por ejemplo, una tarifa administrativa calculada sobre el valor original, seguida de una tarifa de impuesto calculada sobre el valor con la tarifa administrativa ya aplicada.
Es el alias de la cuenta en el ledger donde se acreditarán los ingresos de la tarifa. Cada tarifa puede tener un creditAccount diferente — útil cuando diferentes tarifas necesitan contabilizarse en centros de costo distintos.
"creditAccount": "cuenta-ingresos-tarifas-admin"
Estos campos definen las rutas de las patas contables generadas por el cobro de la tarifa. Son opcionales y permiten rastrear el origen y destino de los movimientos de tarifa en el ledger con granularidad.

​
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 detallados. 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.
Úselo cuando quiera cobrar a clientes según el número de transacciones procesadas — modelo común en plataformas de pago con precios por volumen. Defina escalones de precio (tiers) que se aplican a medida que el volumen crece.
{
  "type": "volume",
  "eventFilter": {
    "transactionRoute": "PIX",
    "status": "approved"
  },
  "pricingModel": "tiered",
  "tiers": [
    { "minQuantity": 0, "maxQuantity": 1000, "unitPrice": "0.50" },
    { "minQuantity": 1001, "unitPrice": "0.30" }
  ],
  "assetCode": "BRL",
  "debitAccountAlias": "cuenta-cliente",
  "creditAccountAlias": "cuenta-ingresos-volumen"
}
El último tier debe ser ilimitado (sin maxQuantity). No puede haber brechas ni superposiciones entre tiers.
Úselo cuando quiera cobrar una tarifa fija periódica por cuenta — por ejemplo, una mensualidad por cuenta activa. Especifique el alcance (segmentId, portfolioId o aliases) y el valor de la tarifa.
{
  "type": "maintenance",
  "feeAmount": "15.00",
  "assetCode": "BRL",
  "maintenanceCreditAccount": "cuenta-ingresos-mantenimiento",
  "accountTarget": {
    "segmentId": "seg_clientes_premium"
  }
}
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. Reglas obligatorias:
  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:
"tiers": [
  { "minQuantity": 0, "maxQuantity": 500, "unitPrice": "0.80" },
  { "minQuantity": 501, "maxQuantity": 2000, "unitPrice": "0.60" },
  { "minQuantity": 2001, "unitPrice": "0.40" }
]
Es una cuota gratuita — un número de transacciones que no se cobran antes de que los tiers comiencen a aplicarse. Útil para modelos de precios con un volumen mínimo incluido.Ejemplo: freeQuota: 100 significa que las primeras 100 transacciones del período no se cobran.
Son escalones de descuento aplicables al billing de volumen. Permiten reducir el valor cobrado según criterios adicionales, complementando la lógica de los tiers principales.
Define cómo se cuentan 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

EndpointCuándo usar
POST /v1/feesCalcular la tarifa real de una transacción en curso. El sistema busca automáticamente los paquetes aplicables según el ledger, segment, ruta y valor. Consulta la referencia de la API Calculate Fees.
POST /v1/estimatesSimular la tarifa de un paquete específico antes de confirmar la transacción. Útil para mostrar al usuario final el costo antes de ejecutar. Consulta la referencia de la API Simulate Fees.
El endpoint recibe los datos de la transacción y el sistema busca automáticamente los paquetes aplicables, considerando:
  • ledgerId — obligatorio
  • segmentId — opcional
  • transactionRoute — opcional
  • Valor de la transacción — comparado con minimumAmount/maximumAmount del paquete
Las tarifas de todos los paquetes correspondientes se calculan y retornan.
El /v1/estimates permite simular la tarifa de un paquete específico (packageId), sin necesitar una transacción real. Ideal para:
  • Mostrar el costo estimado al usuario antes de confirmar.
  • 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 configurar los Billing Packages, use el endpoint:
POST /v1/billing/calculate
Este endpoint procesa las reglas configuradas y genera los cobros para el período informado. Consulta la referencia de la API Calculate Billing.

​
Errores Comunes

La tarifa con priority: 1 debe obligatoriamente tener referenceAmount: "originalAmount". Esto ocurre porque es la primera en calcularse — no hay tarifas anteriores sobre las cuales basar el cálculo.Corrección:
{
  "priority": 1,
  "referenceAmount": "originalAmount"
}
Las tarifas con isDeductibleFrom: true solo pueden usar referenceAmount: "originalAmount". Actualice el campo:
{
  "isDeductibleFrom": true,
  "referenceAmount": "originalAmount"
}
Cuando isDeductibleFrom: true y el tipo es flat, el valor de la tarifa no puede ser mayor que el minimumAmount del paquete. Esto evita escenarios donde la tarifa supera el valor mínimo de la propia transacción.Ejemplo: Si minimumAmount: 100, la tarifa flat no puede exceder 100.
Este error ocurre cuando isDeductibleFrom: true y el tipo es percentage con un valor superior a 100. Una tarifa porcentual deducible del 100% anularía el valor de la transacción — valores superiores son inválidos.
Los tiers de billing de volumen deben cubrir todos los rangos sin brechas. Verifique que el minQuantity de cada tier sea exactamente maxQuantity + 1 del tier anterior.
// ❌ Incorrecto — brecha entre 500 y 600
{ "minQuantity": 0, "maxQuantity": 500, "unitPrice": "0.80" },
{ "minQuantity": 600, "unitPrice": "0.40" }

// ✅ Correcto
{ "minQuantity": 0, "maxQuantity": 500, "unitPrice": "0.80" },
{ "minQuantity": 501, "unitPrice": "0.40" }
El último tier en el billing de volumen debe ser sin límite superior (sin maxQuantity). Esto garantiza que las transacciones por encima del mayor rango definido aún sean tarifadas.
En el billing de tipo maintenance, el campo accountTarget acepta solo una de las tres opciones. No combine campos:
// ❌ Incorrecto
"accountTarget": {
  "segmentId": "seg_abc",
  "portfolioId": "port_xyz"
}

// ✅ Correcto
"accountTarget": {
  "segmentId": "seg_abc"
}
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 use percentage con flatFee.
// ✅ Correcto
"calculationModel": {
  "applicationRule": "flatFee",
  "calculations": [{ "type": "flat", "value": "10.00" }]
}
Análogo al 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. Proporcione 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?
Técnicamente, los registros son soft-deleted (marcados con deletedAt) y no se eliminan de la base de datos. Sin embargo, la API no expone endpoints de restauración por defecto. Contacte al equipo de Lerian si necesita recuperar un registro eliminado accidentalmente. Para la lista completa de códigos de error, consulta la referencia de Códigos de Error.