Cambios de la API

Cada entrada lleva el día en que el cambio llegó a producción. Lo que no está desplegado no aparece aquí.

23 de septiembre de 2026 · Llaves de API, idempotencia, webhooks firmados y cartera de crédito

Makatea-API-Version: 2026-09-23

La API deja de depender de la sesión de un usuario y gana todo lo que necesita una integración de cobranza.

Llaves mk_live_ que el dueño o un administrador crea en Configuración → Desarrolladores.
Cada llave tiene permisos read o write, puede expirar y se revoca al momento.
La llave viaja en Authorization: Bearer o en X-API-Key. Sin llave válida la respuesta es 401. Sin el permiso es 403 insufficient_scope.

El éxito siempre viene en {"data": …} y el error siempre en {"error": {"code", "message", "request_id"}}.
Cada respuesta trae X-Request-Id y Makatea-API-Version: 2026-09-23.
Un parámetro que no existe contesta 400 unknown_parameter con la lista de los permitidos.
Límite de 600 llamadas por minuto por llave, con X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset y Retry-After.

Idempotency-Key en todo POST, PUT, PATCH y DELETE. La misma llave con el mismo cuerpo devuelve la respuesta original durante 24 horas.
La misma llave con otro cuerpo es 422 idempotency_key_reused.

Un solo cursor en todas las listas: pagination.next_cursor y has_more. offset sigue funcionando.
updated_since en clientes, cuotas y pagos ordena por fecha de cambio para sincronizar desde un punto.

13 eventos, de member.created a message.received, entregados desde una cola.
Firma Makatea-Signature: t=…,v1=… con HMAC-SHA256 sobre el cuerpo completo.
8 intentos durante 3 días. Consulta de eventos y entregas, y reintento manual con POST /v1/webhook-deliveries/{id}/retry.

Pagos parciales con fecha real (paid_at) y regla para el excedente.
Libro de pagos con GET /v1/payments. La anulación (POST /v1/payments/{id}/void) queda como renglón negativo.
Condonación, cargos moratorios y saldo a favor por cliente.
PATCH /v1/billing-orders/{id} mueve una cuota de fecha o de cliente y reprograma sus recordatorios.
Créditos con capital e interés por cuota (/v1/credits) y regla de aplicación de pagos configurable.
Liga de pago con la cuenta de pagos de la organización: POST /v1/billing-orders/{id}/payment-link.

Promesas de pago por cliente. Pausan la cobranza hasta su fecha y emiten promise.kept o promise.broken.
POST /v1/messages manda un texto o una plantilla por la línea de la organización.
Conversación de cada cliente e importación del historial con POST /v1/conversations/import.
Documentos adjuntos por cliente, de hasta 15 MB.