Errores
La API v2 devuelve un solo formato de error en toda respuesta ≥ 400. Está diseñado para que puedas manejar errores con código estable y sin parsear texto.Estructura del error
Tipos de error y status HTTP
Ejemplo de manejo (pseudo)
Catálogo de códigos
Los códigos de Comunes, Cesiones y Recaudación ya se emiten en
producción. Las secciones marcadas con ⏳ están en implementación: hoy esos
endpoints devuelven
parameter_missing/parameter_invalid en errores de campo
(con param) y validation_error con mensaje en reglas de negocio; los códigos
específicos listados se están desplegando.Comunes (todas las APIs)
⏳ Facturación — Emisión de documentos
⏳ Facturación — Guía de despacho (DTE 52) y líneas exentas
El batch responde 422 con el mismo cuerpo que v1, no con el sobre de errores v2: los errores van bajodocuments, con la posición del documento como
llave ("0", "1"…) y la ruta del campo adentro. No tienen un code propio:
identifica el campo por su ruta.
Detalle de cada campo en Emisión masiva de documentos (v1), bloque “Guía de Despacho (DTE 52)”.
⏳ Facturación — Campos desconocidos
Un campo que no existe en el documento (por ejemploheader.transfer_indicator)
no se usa al emitir. Según la API key:
- Modo aviso (integraciones existentes): el documento se crea sin ese campo
y la respuesta del batch trae un arreglo
warnings. No es un error: el status es el de un batch aceptado. - Modo estricto (API keys nuevas): la API responde 422 con el campo bajo
documents→ posición → ruta (mismo formato que v1) y no crea el batch.
⏳ Facturación — Avisos de la Resolución 154 (guías de despacho)
Hasta el 31 de octubre de 2026 la guía se emite aunque falten los datos que la Res. Ex. SII N°154 vuelve obligatorios; la respuesta del batch (v1 y v2, con o sin API key) los lista enwarnings con estos códigos. Desde el 1 de noviembre de
2026 los mismos casos responden 422, salvo res154_trailer_plate, que sigue
siendo sólo un aviso.
⏳ Facturación — Boleta de Honorarios (DTE 80/90)
⏳ Credenciales
⏳ SII (emisión y consultas)
Recaudación (cobros / payment requests)
Cesiones
⏳ Documentos Programados
⏳ Webhooks
Ejemplos por escenario
Falta un campo del receptor (validación)
El SII se quedó sin folios
Recurso no encontrado (public ID inexistente)
Límite de solicitudes
Retry-After: 5.
Idempotencia y errores
Los endpoints de escritura (emisión, cobros) aceptan el headerIdempotency-Key.
Si reintentas con la misma key y el mismo body, la API devuelve la respuesta
original sin repetir la operación (no se re-emite al SII). Si reutilizas la
misma key con un body distinto, obtienes idempotency_key_reused (409).