INFRAESTRUCTURA V2.1COREColombia · DIANDIAN Compliant

API de Facturación Electrónica
Integración Fiscal Directa DIAN

Genera, valida y transmite facturas electrónicas directamente con la DIAN sin intermediarios. SIIVRO automatiza XML UBL 2.1, firma digital XAdES-EPES, numeración y cálculo de impuestos (IVA, retefuente, reteICA) a partir del RUT, la resolución y la configuración fiscal del tenant.

<250ms
Latencia DIAN
99.98%
Uptime SLA
UBL 2.1
Estándar DIAN
REST
JSON + XAdES-EPES

Sección 01

Qué significa facturar electrónicamente en Colombia

La DIAN exige que toda factura de venta sea emitida en formato UBL 2.1, firmada digitalmente con un certificado XAdES-EPES de entidad certificadora autorizada, y validada por el WebService oficial antes de ser entregada al receptor. No es opcional y no admite simplificaciones.

Para un desarrollador esto implica: construir XML estructurado, aplicar firma criptográfica, calcular impuestos según actividad económica, consumir SOAP/XML de la DIAN, manejar reintentos y procesar el ApplicationResponse. Son semanas de trabajo especializado.

Sin SIIVRO

Construir XML UBL 2.1 manualmente
Gestionar certificado XAdES-EPES
Calcular IVA / ReteFuente / ReteICA
Consumir SOAP de la DIAN
Manejar reintentos y timeouts
Procesar ApplicationResponse
Mantener según cambios DIAN

Con SIIVRO

Envías JSON con datos de negocio
SIIVRO gestiona el certificado
Motor fiscal automático por tenant
REST sobre HTTPS, no SOAP
Reintentos y colas internas
CUFE + PDF + XML en el response
Actualizaciones DIAN sin código

El principio de SIIVRO: el cliente envía datos de negocio. SIIVRO resuelve la complejidad fiscal. El desarrollador nunca toca XML, firma ni SOAP.


Sección 02

Flujo completo end-to-end

Desde el registro de la empresa hasta la descarga del PDF firmado.

01
Registro de empresa (tenant)Setup

Alta de la empresa en SIIVRO. Cada empresa es un tenant independiente con su configuración fiscal.

02
Carga de RUT y resolución DIANSetup

Se sube el RUT de la empresa y la resolución de facturación electrónica vigente (número, rango, vigencia).

03
Configuración fiscal automáticaAutomático

SIIVRO extrae del RUT: actividad económica, régimen tributario, ciudad, tarifas de ICA y retenciones aplicables.

04
Creación de factura vía APITu código

Tu backend llama POST /V2/invoices con los datos del cliente, ítems y tipo de documento. Sin XML, sin impuestos manuales.

05
Procesamiento interno SIIVROAutomático

SIIVRO construye el XML UBL 2.1, calcula impuestos, aplica la firma XAdES-EPES y prepara la transmisión.

06
Transmisión y validación DIANDIAN

SIIVRO envía el XML al WebService de la DIAN y espera el ApplicationResponse de aceptación o rechazo.

07
Respuesta con CUFE y documentosResponse

Tu backend recibe status, cufe, pdf_path, xml_path y qr_code. La factura tiene validez legal inmediata.

08
Corrección con nota crédito (si aplica)Corrección

Si hay error en la factura aceptada, se emite un tipo 91 referenciando la factura original. No hay eliminaciones.

09
Consulta y descargaConsulta

Consulta el estado de cualquier factura con GET /V2/invoices/{id}. Descarga PDF y XML firmado cuando lo necesites.


Sección 03

Arquitectura multi-tenant

Cada empresa registrada en SIIVRO opera como un tenant independiente. El aislamiento fiscal entre empresas es total: resolución propia, numeración propia, configuración fiscal propia y certificados propios.

Por tenant

Resolución DIAN propia
Rango de numeración propio
Certificado digital
Tarifas de impuestos

Para SaaS

Una integración, N clientes
Cada cliente factura de forma aislada
Sin contaminación de datos
API Key única por tenant

Para ERP

Una empresa por instancia
Múltiples resoluciones vigentes
Facturación interna contable
Control por centro de costo

Sección 04

Tipos de documento soportados

La DIAN define el tipo de documento en el campo document_type. Cada tipo tiene reglas fiscales y estructurales distintas.

01Factura electrónica de venta
Ventas normales B2B y B2CObligatorio para obligados a facturar electrónicamenteDocumento principal ante la DIAN
02Factura de venta de papel
Contingencia cuando el sistema electrónico no está disponibleFacturación fuera del sistema electrónico temporal

NO reemplaza la factura electrónica. Debe ser reportada posteriormente a la DIAN. Tiene implicaciones fiscales si no se regulariza.

91Nota crédito
Corrección de una factura previamente emitidaAnulación parcial o total de una ventaDevolución de mercancía o descuentos posteriores

Es el único mecanismo válido para corregir una factura aceptada.

92Nota débito
Ajustes adicionales sobre una factura existenteCobros adicionales no incluidos en la factura original
95Documento soporte
Compras a proveedores no obligados a facturar electrónicamenteRegistro de costos y deducciones ante la DIAN
96Nota de ajuste
Corrección de documentos soporte (tipo 95)Reversiones de registros de compra

Sección 05

Cálculo automático de impuestos

SIIVRO calcula los impuestos automáticamente a partir de la configuración del tenant (RUT, actividad económica, ciudad). El desarrollador no necesita implementar ninguna lógica fiscal manual. Solo envía el precio base y la tasa de IVA del ítem.

IVAImpuesto al Valor Agregado
Tarifa general: 19%
Bienes exentos: 0%
Servicios excluidos: N/A
Determinado por item/servicio

Fuente: Configurado por ítem en el request

ReteFuenteRetención en la Fuente
Depende actividad económica
Depende tipo de cliente (persona/empresa)
Aplica solo si supera base mínima
SIIVRO calcula y aplica automático

Fuente: Extraído del RUT y tipo de cliente

ReteICARetención de ICA
Varía por ciudad del comprador
Varía por actividad económica
Solo aplica a personas jurídicas
SIIVRO calcula por tarifa municipal

Fuente: Extraído del RUT y ciudad del cliente

Resultado: tú envías price: 100000 y tax_rate: "19.00". SIIVRO calcula IVA, aplica retenciones según el perfil del cliente y entrega los totales correctos a la DIAN.

Sección 06

Campos del request qué es obligatorio y qué resuelve SIIVRO

CampoTipoEstadoDescripción
document_typestringObligatorioTipo de documento DIAN: 01, 91, 92, 95, 96. Define la estructura fiscal del documento.
external_idstringRecomendadoIdentificador único interno de tu sistema. Garantiza idempotencia: si se repite, SIIVRO retorna el resultado original sin crear duplicado.
resolution_numberstringAutomáticoSIIVRO inyecta la resolución activa del tenant. No la envías en el request.
customer.identificationstringObligatorioNIT o cédula del cliente. La DIAN valida su existencia en el RUT.
customer.namestringObligatorioRazón social o nombre completo del cliente.
customer.dvstringRecomendadoDígito de verificación del NIT. Si no se envía, SIIVRO lo calcula.
customer.emailstringOpcionalSi se incluye, SIIVRO envía el PDF automáticamente al correo del cliente.
items[].descriptionstringObligatorioDescripción del bien o servicio. Aparece en el PDF y en el XML.
items[].quantitynumberObligatorioCantidad. Puede ser decimal para servicios fraccionados.
items[].pricenumberObligatorioPrecio unitario antes de impuestos. Debe ser mayor a 0.
items[].tax_ratestringObligatorioTasa de IVA aplicable: 19.00, 5.00 o 0.00 según el bien/servicio.
notesstringOpcionalObservaciones libres. Aparecen en el pie del PDF generado.
billing_referenceobjectCondicionalObligatorio solo para tipos 91 y 92. Referencia la factura original a corregir.

Sección 07

Ejemplo real completo

Request con cliente, múltiples ítems e impuestos. Response con CUFE y documentos generados.

POST /V2/invoices — Request
{
  "document_type": "01",
  "external_id": "ORD-2025-00847",
  "customer": {
    "identification": "901944128",
    "dv": "3",
    "name": "COLABSOFT SAS",
    "email": "contabilidad@colabsoft.com",
    "address": "Calle 72 # 10-07, Bogotá"
  },
  "items": [
    {
      "description": "Licencia plataforma SaaS — Mensual",
      "quantity": 1,
      "price": 250000,
      "tax_rate": "19.00"
    },
    {
      "description": "Soporte técnico prioritario",
      "quantity": 2,
      "price": 50000,
      "tax_rate": "19.00"
    }
  ],
  "notes": "Pago neto 30 días. NIT vendedor: 900123456-1"
}
✓ 201 CREATED — DIAN_ACCEPTED
{
  "id": "inv_9x2kA7p3",
  "status": "DIAN_ACCEPTED",
  "cufe": "a8f3c2d1e9b...7e8273x",
  "dian_date": "2025-04-24T15:32:11-05:00",
  "totals": {
    "subtotal": 350000,
    "iva": 66500,
    "retefuente": 10500,
    "reteica": 3850,
    "total": 402150
  },
  "qr_code": "https://siivro.cloud/v/a8f3c2...",
  "xml_path": "https://storage.siivro.com/xml/inv_9x2kA7p3.xml",
  "pdf_path": "https://storage.siivro.com/pdf/inv_9x2kA7p3.pdf"
}

Sección 08

Respuesta DIAN CUFE y estados

El CUFE (Código Único de Factura Electrónica) es el identificador legal que emite la DIAN al aceptar una factura. Su presencia confirma que el documento tiene plena validez fiscal.

DIAN_ACCEPTED

Factura aceptada. CUFE emitido. Validez legal inmediata.

DIAN_REJECTED

La DIAN rechazó. Ver campo dian_errors. Corregir y reenviar.

PROCESSING

WebService DIAN sin respuesta síncrona. Esperar webhook.

PENDING_SIGN

En cola de firma. Estado transitorio, no requiere acción.


Sección 09

Casos de integración por tipo de sistema

Identifica tu caso y cómo estructurar la integración.

SaaS

Software como Servicio

Arquitectura multi-tenant nativa
Cada cliente factura con su propia resolución
Aislamiento fiscal entre empresas garantizado
Un solo punto de integración para N clientes
Trigger: Evento de conversión o suscripción
ERP

Sistema de Gestión Empresarial

Facturación interna contable automatizada
Integración con módulos de inventario y CxC
Sincronización de resoluciones por empresa
Trazabilidad completa por centro de costo
Trigger: Cierre de orden de venta o despacho
Ecommerce

Comercio Electrónico

Factura automática después del pago confirmado
Webhook de pasarela → endpoint → SIIVRO
Envío automático al email del comprador
Soporte para ventas nacionales e internacionales
Trigger: Webhook payment.confirmed de pasarela
POS

Punto de Venta

Facturación en tiempo real en caja
Soporte contingencia offline (tipo 02)
Impresión térmica del PDF generado
Sincronización posterior en lote
Trigger: Cierre de transacción en caja
TMS

Gestión de Transporte

Facturación por servicio de transporte
Integración con RNDC (Registro Nacional)
Documentos soporte para fletes
Notas crédito por cancelación de viaje
Trigger: Confirmación de entrega o servicio
PMS

Gestión Hotelera

Facturación por estadía al check-out
Servicios adicionales (restaurante, spa, etc.)
Soporte para empresas y personas naturales
Facturas agrupadas por reserva
Trigger: Evento de check-out o cierre de cuenta

Sección 10

Ejemplos de integración Frontend y Backend

SIIVRO se consume exclusivamente desde backend. El frontend solo captura datos y llama a tu propio endpoint.

Frontend — React / Next.jsCaptura datos, llama a tu backend. Nunca a SIIVRO directamente.

React — handleInvoice()
// Correcto: el frontend llama a TU backend
const handleInvoice = async () => {
  const res = await fetch("/api/create-invoice", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      customer: { identification: nit, name: razonSocial },
      items: cartItems.map(item => ({
        description: item.name,
        quantity: item.qty,
        price: item.price,
        tax_rate: "19.00"
      }))
    })
  });
  const { pdf_path, cufe } = await res.json();
  window.open(pdf_path);
};

// INCORRECTO: nunca hagas esto desde el frontend
// fetch("https://api.siivro.com/v1/invoices", {
//   headers: { "Authorization": "Bearer YOUR_KEY" } // expone la key
// });

Backend — Node.js / ExpressAquí vive la integración real con SIIVRO.

Node.js — /api/create-invoice
// POST /api/create-invoice
app.post("/api/create-invoice", async (req, res) => {
  const { customer, items } = req.body;

  if (!customer.identification || !items.length) {
    return res.status(400).json({ error: "Datos incompletos" });
  }

  const siivroRes = await fetch("https://api.siivro.com/v1/invoices", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.SIIVRO_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({ document_type: "01", customer, items })
  });

  const invoice = await siivroRes.json();

  return res.json({
    cufe: invoice.cufe,
    pdf_path: invoice.pdf_path,
    status: invoice.status
  });
});

Backend — Laravel (PHP)

Laravel — InvoiceController.php
// app/Http/Controllers/InvoiceController.php
public function store(Request $request)
{
    $validated = $request->validate([
        'customer.identification' => 'required|string',
        'customer.name'           => 'required|string',
        'items'                   => 'required|array|min:1',
    ]);

    $response = Http::withToken(config('services.siivro.key'))
        ->post('https://api.siivro.com/v1/invoices', [
            'document_type' => '01',
            'customer'      => $validated['customer'],
            'items'         => $validated['items'],
        ]);

    return response()->json([
        'cufe'     => $response['cufe'],
        'pdf_path' => $response['pdf_path'],
        'status'   => $response['status'],
    ]);
}

Sección 11

Errores reales y cómo resolverlos

No errores genéricos. Estos son los que realmente ocurren en producción.

FAD01NIT cliente no encontrado en DIAN
Fix:Verificar identification y dv del customer antes de enviar.
FAD14Número de factura fuera del rango de resolución
Fix:La resolución activa del tenant ya agotó su rango. Cargar nueva resolución.
FAD89Firma digital inválida o expirada
Fix:Renovar certificado en el panel SIIVRO. No requiere cambios en tu código.
400items[0].price debe ser mayor a 0
Fix:Validar que ningún ítem tenga price: 0 o valores negativos.
422document_type inválido para nota crédito sin referencia
Fix:Tipo 91 requiere el campo billing_reference con la factura original.
TIMEOUTWebService DIAN sin respuesta síncrona
Fix:SIIVRO retorna status: PROCESSING. Escuchar webhook para resultado final.

Sección 12

Correcciones nota crédito (tipo 91)

Lo que NO puedes hacer

Eliminar una factura aceptada
Modificar una factura ya transmitida
Reenviar la misma numeración
Anular directamente en el sistema

El proceso correcto

Emitir nota crédito (document_type: 91)
Referenciar la factura original en billing_reference
SIIVRO vincula automáticamente ambos documentos
La DIAN registra la corrección
Nota crédito — POST /V2/invoices
{
  "document_type": "91",
  "customer": {
    "identification": "901944128",
    "name": "COLABSOFT SAS"
  },
  "billing_reference": {
    "invoice_id": "inv_9x2kA7p3",
    "cufe": "a8f3c2d1e9b...7e8273x",
    "reason": "Error en descripción del servicio"
  },
  "items": [
    {
      "description": "Ajuste — Licencia plataforma SaaS",
      "quantity": 1,
      "price": 250000,
      "tax_rate": "19.00"
    }
  ]
}

Sección 13

Contingencia cuando el sistema electrónico no está disponible

La normativa DIAN define tres niveles de contingencia cuando no es posible emitir facturas electrónicas. SIIVRO soporta los tres niveles del Anexo Técnico.

Nivel 1Inmediato

Facturación offline

Emisión de facturas en papel (tipo 02). Se reportan masivamente a la DIAN una vez restablecido el sistema.

Nivel 2Mediano plazo

Sistema alterno

Uso de un sistema de facturación alterno habilitado por la DIAN. Numeración diferenciada.

Nivel 3Regularización

Reporte posterior

Reporte masivo a la DIAN con todas las facturas emitidas durante el período de contingencia.

→ La contingencia se profundiza en la sección dedicada: /docs/contingency


Sección 14

Flujo real en producción

El error más común al integrarse con SIIVRO es asumir que facturar es siempre un flujo síncrono: POST → respuesta → listo. Eso no siempre ocurre. Tu integración debe manejar ambos escenarios desde el primer día.

Caso A — Respuesta síncrona

SIIVRO responde DIAN_ACCEPTED
Tienes CUFE en el response
Puedes mostrar el PDF de inmediato
Flujo termina aquí

Caso B — Respuesta asincrónica

SIIVRO responde PROCESSING
No tienes CUFE aún
NO reenvíes la factura — espera
El resultado llega por webhook

Idempotencia — crítico en producción

Una factura no puede crearse dos veces. En producción es frecuente que el frontend reintente, el backend haga retry por timeout, o el usuario haga doble click. El resultado sin control es doble facturación fiscal.

La solución: envía siempre un external_id único por operación. Si SIIVRO recibe el mismo external_id dos veces, retorna el resultado original sin crear un nuevo documento.

Cuándo reintentar y cuándo no

Reintentar si:

Timeout de red
Error de conexión (5xx)
Status PROCESSING resuelto por webhook

NO reintentar si:

Error 4xx (datos incorrectos)
DIAN_REJECTED (error fiscal)
Factura ya existe con mismo external_id

Sección 15

Webhooks eventos de estado en tiempo real

Cuando la DIAN no responde de forma síncrona, SIIVRO te notifica por webhook en el momento en que se resuelve el estado. Los webhooks son el mecanismo que separa una integración robusta de una frágil. No son opcionales en ambientes productivos reales.

Registro de endpoint

POST /v1/webhooks — Registrar endpoint
{
  "url": "https://tu-sistema.com/webhooks/siivro",
  "events": ["invoice.updated"],
  "secret": "tu_clave_para_validar_firma"
}

Payload del evento invoice.updated

POST https://tu-sistema.com/webhooks/siivro — Payload
{
  "event": "invoice.updated",
  "invoice_id": "inv_9x2kA7p3",
  "external_id": "ORD-2025-00847",
  "status": "DIAN_ACCEPTED",
  "cufe": "a8f3c2d1e9b...7e8273x",
  "pdf_path": "https://storage.siivro.com/pdf/inv_9x2kA7p3.pdf",
  "timestamp": "2025-04-24T15:34:02-05:00",
  "signature": "sha256=abc123..."
}
DIAN_ACCEPTED

Actualizar estado en DB — habilitar descarga PDF — notificar usuario

DIAN_REJECTED

Marcar factura como rechazada — mostrar error — solicitar corrección

Los webhooks pueden repetirse. Tu endpoint debe ser idempotente: si recibes el mismo invoice_id dos veces, no ejecutes la lógica de negocio dos veces. Valida siempre contra el estado actual en tu base de datos.
Valida la firma del webhook. Cada evento incluye un header X-SIIVRO-Signature con firma HMAC-SHA256. Verifica que el payload proviene de SIIVRO antes de ejecutar cualquier lógica. Consulta la guía en /docs/webhooks/security.

Sección 16

Manejo de estados tabla de decisión operativa

Conocer los estados no es suficiente. Lo que importa en producción es saber qué hacer con cada uno.

EstadoQué significaQué debe hacer tu sistemaQué NO hacer
PROCESSINGDIAN no respondió aúnEsperar webhook invoice.updatedNO reenviar la factura
DIAN_ACCEPTEDFactura válida con CUFEMostrar PDF / guardar CUFENO modificar ni reenviar
DIAN_REJECTEDError fiscal en la facturaCorregir datos y reenviarNO reenviar sin corregir
PENDING_SIGNEn cola interna de firmaNo hacer nada — estado transitorioNO asumir error

Esta tabla no es información — es comportamiento. La diferencia entre una integración que escala y una que genera incidencias en producción es haber implementado estas reglas desde el inicio.


Sección 17

Versionado de API

Todas las rutas de la API incluyen la versión como prefijo. Esto garantiza que tu integración no se rompa ante cambios internos o actualizaciones del motor fiscal.

Versión actual

/V2.1/invoices

Versión estable en producción. Se recomienda siempre integrar con la versión más reciente para acceder a las últimas capacidades fiscales.

Versiones futuras

/V3/invoices

Cuando se introduzcan cambios con ruptura de compatibilidad, SIIVRO publica una nueva versión. La anterior sigue funcionando hasta su retiro formal.

Garantías de retrocompatibilidad

SIIVRO no rompe versiones existentes sin aviso formal.
Cambios que afecten la estructura del request o el response implican una nueva versión mayor.
Campos nuevos opcionales pueden agregarse a versiones existentes sin considerarse una ruptura.
Los endpoints de consulta GET mantienen su estructura mientras la versión esté activa.

Política de notificación de cambios

SIIVRO notifica con mínimo 30 días de anticipación cualquier cambio relevante en la API. Los cambios mayores pasan por un programa beta con usuarios seleccionados antes del lanzamiento general.


Sección 18

Límites de tasa rate limiting

Los límites de tasa protegen la estabilidad de la plataforma y garantizan disponibilidad uniforme para todos los tenants.

Creación de facturas

60 req / min

Por tenant

Consultas GET

300 req / min

Por tenant

Registro de webhooks

10 req / min

Por tenant

Descarga de documentos

120 req / min

Por tenant

Headers de respuesta relevantes

X-RateLimit-LimitLímite total de requests para el período actual.
X-RateLimit-RemainingRequests disponibles en el período actual.
X-RateLimit-ResetTimestamp UNIX cuando el contador se reinicia.
Retry-AfterSegundos a esperar antes de reintentar (solo en 429).
Si superas el límite, la API retorna HTTP 429 Too Many Requests. Implementa backoff exponencial en tus clientes. Los límites por plan se detallan en /docs/rate-limits.

Sección 19

Seguridad — diseñado para ambientes productivos reales

La seguridad de SIIVRO va más allá de HTTPS y API Keys. Cada capa está diseñada para ambientes donde la información fiscal tiene valor legal y no admite compromisos.

API Keys — privadas y rotables

Solo se usan desde backend. Nunca en frontend.
Se pueden regenerar en cualquier momento desde el panel.
La rotación no interrumpe facturas en curso.
Cada key queda registrada en el log de acceso.

Firma de webhooks

Cada evento incluye firma HMAC-SHA256.
Verifica el header X-SIIVRO-Signature antes de procesar.
Rechaza eventos sin firma válida.
El secreto de firma es configurable por tenant.

Scopes y permisos

Las keys pueden limitarse a operaciones específicas.
Ejemplo: key solo lectura para reportes.
Ejemplo: key solo escritura para creación de facturas.
Configuración por tenant en el panel SIIVRO.

IP Whitelisting (opcional)

Restringe el acceso a rangos de IP autorizados.
Ideal para entornos corporativos con IP fija.
Configurable por tenant desde el panel.
Recomendado para integraciones ERP críticas.

Sección 20

Qué NO hacer en producción

Experiencia condensada de integraciones reales. Los errores aquí listados son los que generan incidencias fiscales, doble facturación o rechazos masivos de la DIAN.

No facturar sin validar el NIT del cliente

La DIAN valida el NIT del receptor contra el RUT. Un NIT inválido resulta en rechazo inmediato (FAD01). Valida el NIT antes de presentarlo al usuario como opción.

No reenviar requests sin control de idempotencia

Reintentar sin external_id puede crear múltiples facturas por la misma operación. Siempre envía un external_id único por transacción y controla si ya fue procesada.

No confiar en los datos que vienen del frontend

El frontend puede ser manipulado. Valida cantidades, precios y datos del cliente en tu backend antes de enviarlos a SIIVRO. Un price: 0 o un NIT vacío genera error inmediato.

No intentar borrar facturas aceptadas

Una factura aceptada por la DIAN es un documento fiscal con validez legal. No existe endpoint de eliminación. El único mecanismo es una nota crédito (tipo 91).

No ignorar el estado PROCESSING

PROCESSING no es un error. Es un estado válido que indica que la DIAN no respondió de forma síncrona. Escucha el webhook y actualiza tu sistema cuando llegue el resultado.

No hardcodear la resolución DIAN en el código

Las resoluciones tienen fechas de vencimiento y rangos de numeración. Cuando se agotan o vencen, el sistema falla. SIIVRO gestiona la resolución activa automáticamente.

No exponer la API Key en el frontend o repositorios

La API Key de SIIVRO tiene acceso a toda la facturación del tenant. Nunca la incluyas en código cliente, variables de entorno públicas o repositorios de código.


Sección 21

Por qué esta arquitectura escala mejor

No se trata solo de que SIIVRO sea una API REST en lugar de SOAP. Se trata de cómo está construido cada componente para reducir puntos de fallo, latencia y carga operativa.

Menos latencia

SIIVRO se comunica directamente con el WebService de la DIAN sin capas de intermediación. Menos saltos, menos tiempo de espera, menos puntos de fallo.

Menos dependencias en tu stack

Sin librerías de firma criptográfica, sin parsers XML, sin clientes SOAP, sin gestión de certificados. Tu codebase es más pequeño y más mantenible.

Menos puntos de fallo

La complejidad fiscal vive en SIIVRO. Tu backend solo hace HTTP POST. Si la DIAN cambia su esquema, SIIVRO se actualiza sin que toques código.

Más escalabilidad multi-tenant

La arquitectura multi-tenant nativa permite agregar N empresas sin duplicar infraestructura. Un solo punto de integración gestiona múltiples clientes.

El resultado práctico: menos código, menos infraestructura y menos operación fiscal manual. Esto no es solo una API de facturación — es la capa fiscal completa de tu producto, lista para producción desde el primer request.


Sección 22

Preguntas frecuentes


Sección 23

Timeline de una factura en producción

De request a CUFE. Qué hace el sistema en cada momento y qué debe hacer tu código.

T0Request enviado
T1PROCESSING
T2Webhook recibido
T3Estado final

Sistema

SIIVRO recibe el JSON, lo valida y lo encola para firma XAdES-EPES.

Tu código

Guarda el external_id en tu base de datos con estado PENDING.

Sistema

SIIVRO firma el XML, lo transmite al WebService DIAN y espera el ApplicationResponse.

Tu código

No reenvíes. No modifiques. Espera el webhook.

Sistema

SIIVRO notifica el resultado via POST a tu endpoint con firma HMAC-SHA256.

Tu código

Valida la firma. Actualiza el estado en tu DB. No ejecutes lógica duplicada.

Sistema

La factura queda en DIAN_ACCEPTED (con CUFE) o DIAN_REJECTED (con dian_errors).

Tu código

ACCEPTED — habilita descarga del PDF. REJECTED — muestra error y permite corrección.

La regla de oro: en T1 (PROCESSING) tu sistema no debe hacer nada excepto esperar. Un reenvío en ese estado crea doble factura. El webhook en T2 es la única señal válida para actuar.


Sección 24

Error DIAN real caso completo con corrección

No un error abstracto. El escenario real más frecuente en producción: NIT de cliente inválido. Qué salió mal, qué respondió el sistema y cómo se corrige paso a paso.

PARTE 1Qué salió mal

El sistema envía una factura tipo 01 con el NIT del cliente obtenido directamente del formulario web, sin validar el dígito de verificación. El campo customer.identification tiene un dígito transpuesto: se envía "901944218" en lugar de "901944128". La DIAN consulta el RUT y no encuentra ese NIT registrado.

PARTE 2Respuesta del sistema
Response — 422 DIAN_REJECTED
{
  "id": "inv_7h3nB2q1",
  "status": "DIAN_REJECTED",
  "cufe": null,
  "dian_errors": [
    {
      "code": "FAD01",
      "message": "NIT del receptor no encontrado en el RUT de la DIAN.",
      "field": "customer.identification",
      "value_sent": "901944218"
    }
  ],
  "created_at": "2025-04-24T16:10:44-05:00"
}

Nota importante: esto no es un error técnico de la API. Es un error fiscal. La factura no existe ante la DIAN. El NIT enviado no está en el RUT.

PARTE 3Corrección paso a paso
01

Leer dian_errors[0].field

El campo culpable es customer.identification. El valor enviado fue 901944218.

02

Validar el NIT correcto

Consulta al usuario o valida con la DIAN. El NIT real de la empresa es 901944128 con DV 3.

03

Generar un nuevo external_id

No reutilices el external_id de la factura rechazada. Genera uno nuevo: ORD-2025-00847-R1.

04

Reenviar el request con el NIT corregido

Envía el mismo request con customer.identification: '901944128', dv: '3' y el nuevo external_id.

05

Verificar DIAN_ACCEPTED y guardar CUFE

El response exitoso incluye cufe, pdf_path y xml_path. La factura corregida tiene validez legal.

Conclusión: FAD01 nunca es un bug de SIIVRO. Siempre es un dato de negocio incorrecto. Valida el NIT del cliente antes de enviarlo no después del rechazo.


Sección 25

Testing sandbox mindset antes de producción

El entorno sandbox es idéntico al productivo en comportamiento. Si algo falla aquí, fallará en producción. No es un entorno de juguete.

Modo sandbox

No afecta la DIAN real bajo ninguna circunstancia
Facturas ilimitadas sin costo durante pruebas
Respuestas coherentes con el comportamiento real
Webhook funciona igual que en producción

Qué probar

Factura válida — ACCEPTED con CUFE
NIT inválido — REJECTED con FAD01
Timeout simulado — PROCESSING + webhook
Idempotencia — mismo external_id, un resultado

Escenarios adversos

Nota crédito sin billing_reference — 422
price: 0 en un ítem — 400
API Key incorrecta — 401
Rate limit: más de 60 req/min — 429

Checklist de salida a producción

Factura válida — status: DIAN_ACCEPTED, CUFE retornado
Factura con NIT inválido — status: DIAN_REJECTED, código FAD01
Factura con resolución agotada — status: DIAN_REJECTED, código FAD14
Mismo external_id dos veces — segunda request retorna resultado original
Factura tipo 91 sin billing_reference — error 422 inmediato
Webhook configurado — recibes evento invoice.updated al cambiar estado
Rate limiting — 60 facturas/min; la 61 retorna HTTP 429
API Key expuesta en frontend — nunca, aunque sea sandbox
La regla del sandbox: si no probaste el caso en sandbox, no existe en tu integración. Un escenario no probado es un incidente fiscal esperando ocurrir.

Sección 26

Observabilidad logs, trazabilidad y auditoría

Una integración enterprise no solo emite facturas. Puede responder en cualquier momento: "¿qué pasó con esta factura?" con precisión y evidencia completa.

Logs por factura

invoice_id único por documento
external_id para correlacionar con tu sistema
timestamp de cada transición de estado
Payload del request original guardado
Código de error DIAN si aplica

Trazabilidad completa

GET /v1/invoices/{id} — estado actual
GET /V2/invoices/{id}/events historial
Desde PENDING_SIGN hasta DIAN_ACCEPTED
Cada webhook enviado queda registrado
Timestamps en zona horaria Colombia (UTC-5)

Auditoría fiscal

Quién generó la factura (user_id del tenant)
Desde qué IP se originó el request
Certificado digital utilizado para la firma
ApplicationResponse original de la DIAN
XML firmado archivado por 10 años

Trazabilidad por invoice_id — endpoint de eventos

GET /v1/invoices/inv_9x2kA7p3/events
{
  "invoice_id": "inv_9x2kA7p3",
  "external_id": "ORD-2025-00847",
  "events": [
    {
      "status": "PENDING_SIGN",
      "timestamp": "2025-04-24T15:32:00-05:00",
      "actor": "system"
    },
    {
      "status": "PROCESSING",
      "timestamp": "2025-04-24T15:32:01-05:00",
      "actor": "system",
      "detail": "XML firmado. Transmitiendo a DIAN."
    },
    {
      "status": "DIAN_ACCEPTED",
      "timestamp": "2025-04-24T15:32:11-05:00",
      "actor": "dian",
      "cufe": "a8f3c2d1e9b...7e8273x",
      "detail": "ApplicationResponse recibido y procesado."
    }
  ],
  "webhook_sent": true,
  "webhook_attempts": 1,
  "webhook_last_status": 200
}

La pregunta que debes poder responder siempre

Un cliente dice: "me cobraron pero no llegó la factura". Con SIIVRO puedes responder en segundos: qué estado tiene la factura, si el webhook se entregó, cuándo ocurrió cada transición, y dónde está el PDF firmado. Eso no es soporte — es trazabilidad fiscal completa.

→ Guía de observabilidad avanzada y retención de logs en /docs/observability


Sección 27 Playground · Demo Interactivo

Playground Simula la API sin backend real

Simula el comportamiento real del endpoint POST /V2/invoices sin backend real, sin DIAN, sin certificados. El motor de simulación aplica las mismas reglas que producción: validaciones, estados, idempotencia, webhooks y rate limiting. Cuando estés listo, solo reemplazas el simulador por la API real sin cambiar tu código.

Autorización simulada activa. En producción este endpoint requiereAuthorization: Bearer <API_KEY> desde backend. Nunca expongas tu API Key en el frontend.
MODO SANDBOX0 requests enviadosLímite: 5 / 30s (demo)LISTO
POST /V2/invoices
document_type: "01"

Envía el mismo external_id dos veces → verás idempotencia en acción

customer

Ítem 1
Ítem 2

Totales estimados (pre-simulación)

Subtotal$ 350.000
IVA$ 66.500
ReteFuente-$ 8.750
ReteICA-$ 1.925
Total$ 405.825

Escenarios de prueba rápida

Response Panel
LISTO

Completa el formulario y haz clic en Emitir factura para ver la respuesta simulada de la API.

Prueba diferentes NITs para ver ACCEPTED, REJECTED o PROCESSING.

api.siivro.com · v2.1 · Sandbox simuladoSin requests aún

Guía de escenarios — qué probar y qué aprenderás

AACCEPTED — flujo feliz

El response incluye CUFE, PDF y totales fiscales calculados automáticamente. Este es el flujo del 95% de tus facturas en producción.

NIT de prueba: 901944128

BREJECTED — NIT inválido (FAD01)

La DIAN rechaza porque el NIT no existe en el RUT. Ver dian_errors[0].field para saber exactamente qué corregir.

NIT de prueba: 000000000

CPROCESSING → webhook

La DIAN no responde de forma síncrona. El sistema retorna PROCESSING. Después llega el webhook con el estado final. NO reenvíes.

NIT de prueba: 900100200

DIdempotencia

Envía el mismo external_id dos veces. El sistema retorna el resultado original sin crear una nueva factura. Esto evita doble facturación.

NIT de prueba: 901944128

ERate limit (429)

Envía más de 5 requests en 30 segundos. El sistema responde con 429 y Retry-After. Implementa backoff exponencial en producción.

NIT de prueba: 901944128

FPrice: 0 → error 400

Pon price: 0 en cualquier ítem. El validador rechaza antes de llegar a la DIAN. Siempre valida en tu backend antes de enviar.

NIT de prueba: 901944128

El Playground no es un juguete. Es una simulación fiel del comportamiento real de la API. Si tu integración pasa todos los escenarios aquí, está lista para producción. Solo cambia la URL del simulador por https://api.siivro.com/v1/invoices y agrega tu API Key desde backend. Sin cambiar una línea más.