Skip to main content

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

Maneja los errores por code (estable), no por message (puede cambiar) ni por el status HTTP solo (varios code comparten status).

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 bajo documents, 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 ejemplo header.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.
Un aviso significa que el dato no llegó al documento: con header.transfer_indicator la guía sale como venta (transport_type "1") y con export_data.export_clause la factura de exportación sale sin cláusula de venta.

⏳ 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 en warnings 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.
Detalle de cada campo y de la anulación de guías en Emisión masiva de documentos (v2), sección “Resolución 154”.

⏳ 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

Respuesta incluye el header Retry-After: 5.

Idempotencia y errores

Los endpoints de escritura (emisión, cobros) aceptan el header Idempotency-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).