Vas a lograr ver qué cambió en la API pública versión a versión.
​
v1.7.0: de quién es cada teléfono
  • POST /v1/portfolios/:id/debtors acepta owner en cada ítem de contactInfoPhoneNumbers: holder, third_party, reference, guarantor o unknown. Es opcional: sin valor, el número queda unknown
  • Las lecturas de deudores muestran owner y ownerSource en cada teléfono
  • En un número que ya existía, owner solo cambia si viene en el request
​
v1.6.0: consentimiento y baja de contacto al cargar deudores
  • POST /v1/portfolios/:id/debtors acepta cinco campos booleanos opcionales: complianceOptOut, complianceConsentToCall, complianceConsentToWhatsapp, complianceConsentToEmail y complianceConsentToSms. Al crear, si no vienen, el deudor nace con los defaults de siempre; en una actualización un campo ausente no se toca
  • complianceOptOut: true registra la baja igual que un pedido del deudor (nota, línea de tiempo y cancelación de mensajes de WhatsApp pendientes)
​
v1.5.0: contrato de pagos, límites y webhooks más estricto
  • POST /v1/portfolios/:id/debtors suma dos valores a reason.code: erased_subject y debt_currency_invalid. El enum es cerrado: los clientes que validan estrictamente los valores tienen que agregarlos
  • POST /v1/payments responde 400 validation_error cuando la moneda no se puede derivar o no es un código ISO 4217 (antes caía en MXN)
  • POST /v1/payments responde 409 idempotency_conflict si el externalId ya se usó en la cartera con otro cuerpo; con el mismo cuerpo sigue devolviendo 200 con el pago existente. El pago ahora trae externalId (null si no se cargó por ese endpoint)
  • GET /v1/debtors: status acepta una lista separada por comas (desde el 2026-09-14)
  • Un valor desconocido en status o direction responde 400 validation_error en vez de 500
  • POST /v1/portfolios/:id/imports respeta Idempotency-Key
  • Webhooks: la URL tiene que ser https pública y no se siguen redirecciones. Cada payload suma livemode: false para eventos de carteras sandbox, true para el resto
  • limit queda documentado: default 50, de 1 a 100, y un valor fuera de rango se recorta en vez de rechazarse. error.code pasa a ser un enum cerrado en la spec
​
v1.4.0: los mensajes de error vuelven en inglés
  • El message del sobre de error (todos los endpoints, incluidos los motivos por ítem de POST /v1/portfolios/:id/debtors) ahora es texto en inglés en vez de español. El code no cambia: cualquier integración que ramificaba su lógica por el texto de message en vez de por code tiene que actualizarse; code siempre fue, y sigue siendo, la forma soportada de manejar un error
  • Una respuesta guardada por Idempotency-Key sigue reproduciendo el message en español hasta que esa clave vence (24 horas, ver Deudores): sólo una request nueva después de ese margen ve el mensaje en inglés
​
v1.3.0 — rate limit ponderado por ítems y claves acotadas por cartera
  • POST /v1/portfolios/:id/debtors ahora cobra el rate limit por el tamaño real del lote: 1 unidad cada 50 deudores (mínimo 1), en vez de la unidad fija por request del resto de la API. Un lote de 500 deudores cuesta 10 unidades. X-RateLimit-Remaining en la respuesta de ese endpoint ya refleja el cobro del lote entero (ver Paginación, errores y límites)
  • Una clave de API puede emitirse acotada a un subconjunto de carteras de tu organización. Con una clave acotada, cualquier cartera fuera de la lista responde 404 not_found, igual que una cartera de otra organización, y los listados devuelven sólo lo que cae dentro de las carteras habilitadas (ver Autenticación). Pedíselo a tu contacto en Mozart al solicitar la clave
​
v1.2.0 — escritura masiva de deudores
Escritura masiva de deudores, con sus deudas, en un solo lote:
  • POST /v1/portfolios/:id/debtors — crear o actualizar hasta 500 deudores por request, con resultado por ítem, idempotente por externalId y por la cabecera Idempotency-Key (ver Deudores)
  • externalId nuevo en la respuesta de GET /v1/debtors y GET /v1/debtors/:id
  • Códigos de error nuevos: payload_too_large (413, lote de más de 500 deudores) e idempotency_conflict (409, misma Idempotency-Key con otro cuerpo)
  • 2026-09-18 (fix posterior): POST /v1/portfolios/:id/debtors suma un tope de 5 MB por cuerpo de request (413 payload_too_large, además del tope de 500 ítems) y un octavo motivo de rechazo por ítem, debt_duplicate_in_batch (dos ítems del mismo lote declarando la misma deuda nueva)
El resto de la API sigue igual.
​
v1.1.0 — escritura y webhooks
Primera versión con escritura y con eventos en tiempo real.Escritura, con una clave con el scope write (ver Autenticación):
  • POST /v1/payments — registrar un pago, idempotente por externalId (ver Pagos)
  • POST /v1/portfolios/:id/imports/upload-url, POST /v1/portfolios/:id/imports, GET /v1/imports/:id — cargar un CSV de deudores y deudas a una cartera existente (ver Carga de cartera)
Webhooks, dados de alta desde el backoffice de Mozart: call.completed, promise.created y payment.registered, firmados con X-Mozart-Signature (ver Webhooks).El resto de la API sigue igual: sólo read para todo lo demás.
​
v1.0.0 — lectura
Primera versión pública de la API. Sólo lectura, sobre los datos de tu organización:
  • GET /v1/me
  • GET /v1/portfolios, GET /v1/portfolios/:id
  • GET /v1/debtors, GET /v1/debtors/:id
  • GET /v1/debts, GET /v1/debts/:id
  • GET /v1/calls, GET /v1/calls/:id (con análisis post-llamada)
  • GET /v1/payments, GET /v1/payments/:id
  • GET /v1/promises
  • GET /v1/campaigns, GET /v1/campaigns/:id
Autenticación por clave de API (Authorization: Bearer), paginación por cursor y límite de 300 requests por minuto por clave. Ver Paginación, errores y límites para el detalle.

​
Qué viene

Nuevas líneas de trabajo se publican acá cuando tengan una versión lista.