Skip to main content

Novedades APIDIAN 2026

Boletín de actualizaciones de la API de Facturación Electrónica DIAN. Aquí encontrará, mes a mes, las nuevas funcionalidades y mejoras más importantes de la plataforma. Las novedades más recientes aparecen primero.

Octubre 2026​

Seguridad: las consultas y descargas por NIT ahora exigen token​

API
Requiere acción si su sistema consume estas rutas

Hasta ahora, varias rutas de la API respondían sin ninguna autenticación: bastaba conocer el NIT de una empresa (dato público, impreso en cada factura) y el nombre del archivo para consultar o descargar sus documentos. Desde esta versión todas exigen el api_token del usuario dueño de la empresa, el mismo que ya se usa para emitir documentos en /api/ubl2.1/.... Si su sistema las llama sin token, dejará de recibir respuesta al actualizar.

Rutas afectadas. Las URL no cambian; solo hay que agregar el token.

RutaPara qué sirve
GET /api/information/{nit} y sus variantes /{desde}, /{desde}/{hasta} y /page/{page}/pageListado de documentos emitidos
GET /api/total_documents/{nit} y sus variantes /{desde} y /{desde}/{hasta}Totales de documentos por tipo
GET /api/invoice/{nit}/{archivo}Descarga del XML o PDF de un documento
GET /api/receivedfile/{nit}/{archivo}Descarga de archivos de documentos recibidos
GET /api/view/{nit}/{archivo}Visualización de XML o PDF en el navegador
GET /api/invoice/xml/{archivo} y GET /api/invoice/pdf/{archivo} (también sin el prefijo /api)Descarga por nombre de archivo. Rutas antiguas: prefiera /api/invoice/{nit}/{archivo}
GET /api/download/{nit}/{archivo}/{BASE64|INLINE}Descarga con opción BASE64 o INLINE. Por ahora sigue aceptando llamadas sin token; se cerrará en una próxima versión, agregue el token desde ya

Cómo enviar el token, de cualquiera de las dos formas:

Authorization: Bearer SU_TOKEN        (cabecera HTTP, recomendada)
?api_token=SU_TOKEN                   (al final de la URL)

Respuestas si falta o no corresponde, siempre en JSON:

  • Sin token: 401 {"success": false, "message": "No autenticado. Esta consulta requiere un api_token valido."}
  • Con el token de otra empresa: 403 {"success": false, "message": "No tienes acceso a esta empresa."}

Con el token correcto la respuesta es exactamente la misma de siempre: no cambió el formato, los campos ni los filtros.

Qué no cambia:

  • Las rutas /api/ubl2.1/... ya exigían token y no requieren ningún ajuste.
  • El panel de administración y los portales de adquiriente, vendedor, empleado y owner siguen funcionando igual. Sus botones de descarga ahora usan enlaces firmados con caducidad de 2 horas; si uno caduca, basta recargar la página.

Recomendaciones:

  • No incluya enlaces a /api/download/... ni a /api/invoice/... en correos o páginas dirigidas a terceros (por ejemplo en el html_buttons del correo al adquiriente): dejarán de funcionar sin token, y el api_token nunca debe compartirse con el cliente final. Los correos que envía la plataforma ya adjuntan el PDF y el XML.
  • Si administra su propia instalación y algún sistema todavía no puede enviar el token, puede abrir un periodo de gracia temporal en el .env: ALLOW_PUBLIC_RESUME=true para las consultas y ALLOW_PUBLIC_FILES=true para los archivos, seguido de php artisan config:clear. Cada llamada sin token queda registrada en storage/logs/laravel.log con el texto "periodo de gracia", para identificar qué sistema falta por adaptar. Ciérrelo tan pronto termine.
note

Al actualizar: esta versión no incluye migraciones. Limpie las cachés de configuración, rutas y vistas (php artisan config:clear, route:clear y view:clear). La colección Postman ya incluye este aviso y documenta el token en los endpoints afectados que contiene.

Avisos de vencimiento de certificados y resoluciones​

Interfaz

La plataforma ahora avisa con anticipación cuando el certificado de firma digital o alguna resolución de facturación está por vencer, para que no se interrumpa la emisión:

  • Campanita en el encabezado del panel con los vencimientos de las empresas del usuario conectado: aparecen los que vencen en los próximos 30 días y se resaltan en rojo los que vencen en 7 días o menos o ya vencieron. Cada aviso lleva a la pantalla donde se renueva.
  • Correo diario de aviso a la dirección del usuario dueño de cada empresa, con el detalle de lo que vence. Sale con el servidor de correo propio de la empresa si lo tiene configurado, no se repite para el mismo vencimiento y puede lanzarse a mano con php artisan expirations:notify (requiere tener activo el cron de schedule:run).
  • El listado de empresas muestra el estado del certificado y la resolución que vence primero, con un resumen de vencidos y por vencer.

Listado de empresas: estado del certificado y de la configuración​

Interfaz

El listado de empresas incorpora dos columnas nuevas y una pantalla para completar lo que falta:

  • Certificado: Vigente, Por vencer, Vencido, Sin fecha o Sin certificado. Los certificados antiguos que no tenían fecha de vencimiento registrada la recuperan automáticamente del archivo .p12.
  • Configuración: indica si la empresa tiene el software (ID y PIN) de cada tipo de documento y sus resoluciones de factura, con el detalle por tipo. Ambas columnas se pueden filtrar.
  • Completar configuración: nueva pantalla que reúne certificado, software y resolución de factura (y opcionalmente la de nota crédito) en un solo lugar, para las empresas creadas por la API o por el asistente a las que se les saltó algún paso. En habilitación viene precargada con la resolución de pruebas de la DIAN.

Reenvíos duplicados que quedaban "en proceso"​

APIInterfaz

Cuando un facturador reenviaba un número mientras la DIAN todavía validaba el primer envío, quedaban dos registros: uno validado y otro "en proceso" para siempre, que bloqueaba el consecutivo y confundía en el listado. Ahora el registro repetido se marca como DUPLICADO con el CUFE del que sí quedó validado, deja de verse "en proceso" y la API responde con los datos del documento validado (CUFE, cliente y total) en lugar de pedir que se consulte un documento que la DIAN nunca procesó.

Responsabilidades fiscales en los PDF​

InterfazAPI

Todas las plantillas de factura, POS, notas, documento soporte, nómina y eventos imprimen en el encabezado las responsabilidades fiscales de la empresa (campo type_liability_names registrado en la configuración de la empresa; si no está, se usa la obligación principal). Cuando la obligación es "R-99-PN No aplica" el texto se omite en lugar de imprimir "No aplica".

Correcciones destacadas​

API
  • Vista previa de documento soporte con vendedor del exterior: ya resuelve el país por su código y toma municipio y departamento en texto libre, como el envío definitivo.

Septiembre 2026​

Documentos "en proceso" en la DIAN (código 98)​

APIInterfaz

La DIAN comenzó a responder muchos envíos con el estado "En proceso" (código 98) en lugar de validar o rechazar el documento en el momento. Antes ese caso se veía como un documento no válido, sin AttachedDocument ni correo, y al reenviarlo la DIAN lo rechazaba por la regla 90 "Documento procesado anteriormente". La plataforma ahora reconoce ese estado y lo resuelve de punta a punta:

  • Toda respuesta de la API incluye el campo dian_status (VALIDADA, RECHAZADA, EN_PROCESO o NO_ENCONTRADO) con un mensaje de qué hacer. Si el documento quedó en proceso, la respuesta trae además la URL exacta de consulta y la espera sugerida. Los envíos del set de pruebas y por lote también lo reportan, con la URL de consulta por ZipKey.
  • El número queda reservado mientras la DIAN decide: un reenvío con el mismo prefijo y número no sale a la DIAN, y los endpoints de consecutivo saltan los números en proceso. El reenvío puede forzarse con ignore_document_in_process.
  • La consulta de estado por CUFE cierra el ciclo cuando la DIAN confirma: genera el AttachedDocument, marca el documento como válido y envía el correo. Ya no falla con documentos cuyo adquiriente no está registrado en la plataforma.
  • En la interfaz los documentos en proceso se resaltan en amarillo, con el botón Consultar DIAN por documento y Consultar pendientes en la DIAN para toda la página. El botón ESTADO desaparece: solo se marca como válido lo que la DIAN confirma.
  • Consulta automática: una tarea programada revisa cada 10 minutos los documentos en proceso y los deja al día (requiere tener activo el cron de schedule:run).
note

Al actualizar: esta versión incluye migraciones de base de datos. Después de actualizar el código ejecute php artisan migrate. Vea el proceso completo en Actualización.

Correo al adquiriente y AttachedDocument desde el listado​

InterfazAPI

El envío del correo y la consulta del AttachedDocument ahora funcionan igual para todos los tipos de documento desde el listado de la empresa:

  • Estado del correo y botón Enviar / Reenviar en facturas, notas, documentos equivalentes y documento soporte, mostrando a qué dirección se envía.
  • Si el cliente no tiene correo registrado, la plataforma lo indica en lugar de fallar, y cualquier error de envío queda guardado y visible.
  • Corregido el envío del correo al empleado en nómina electrónica, tanto al generar la nómina como desde la interfaz.
  • Botón Attached para ver el AttachedDocument de cualquier tipo de documento, incluido el documento soporte. Para documentos anteriores a esta versión, la respuesta de la DIAN se recupera del archivo en disco.

Paso a producción: espera automática del set de pruebas​

Interfaz

El asistente de paso a producción ahora acompaña toda la validación del set de pruebas sin intervención manual:

  • Ya no se detiene cuando la DIAN responde "consulte más tarde": espera 25 segundos, reintenta cada 15 segundos hasta por 15 minutos y muestra el intento y el tiempo transcurrido.
  • El ZipKey se conserva en el navegador: puede cerrar la página y retomar después con «Consultar ahora», o pegar el ZipKey de un envío anterior, sin reenviar el documento de prueba ni gastar consecutivos.
  • El ambiente cambia a Producción solo cuando la DIAN aprueba. Si el tipo de documento ya está en producción, el asistente lo advierte, porque un ZipKey del set de pruebas nunca resolvería contra ese ambiente.
  • La consulta del ZipKey usa la bandera del tipo de documento correcto (facturas o documentos equivalentes). Antes las facturas se consultaban como POS y quedaban "en proceso" indefinidamente en empresas con POS en producción.

Nueva plantilla gráfica para factura de venta​

Interfaz

Se incorpora la plantilla 14 para factura de venta, con datos completos del adquiriente, lote y fecha de vencimiento por ítem, atributos del producto y plan de pagos con su frecuencia. Los campos de lote y vencimiento se agregaron también a las plantillas existentes.

Fabricante del software en el lateral de la factura​

API

Enviando software_manufacturer (razón social, NIT y nombre del software) en el JSON de la factura, la representación gráfica imprime en el margen lateral el texto "Fabricante Software y Proveedor tecnológico" en todas las plantillas de factura.

Mejoras para quienes integran desde su propio sistema​

API

Ajustes en los endpoints más usados desde sistemas externos:

  • Las notas crédito y débito, y la nota de ajuste de documento soporte, aceptan billing_reference.prefix con el prefijo de la factura referenciada, que se refleja en el XML y en el PDF.
  • El endpoint de próximo consecutivo compara el prefijo sin distinguir mayúsculas ni espacios y, cuando no existe la resolución, responde con un mensaje claro y la lista de prefijos disponibles.
  • Nuevo endpoint GET /api/ubl2.1/config/query/{nit} que devuelve la configuración de la empresa (identificación, responsabilidades, ubicación, ambientes por tipo de documento y certificado), pensado para que el facturador web (PRO3) y otros sistemas importen la empresa desde la API.
  • Servidor de correo (SMTP) configurable por API: PUT /api/ubl2.1/config/smtp registra el SMTP propio de la empresa del token (si se envía sin mail_host, la empresa vuelve al SMTP general). Para el SMTP general del servidor, PUT /api/ubl2.1/config/smtp-global lo escribe en el .env, autenticado con la clave SMTP_ADMIN_TOKEN.
  • Mensajes de error más claros: la API ya no responde "Internal Server Error" genérico. Cada error llega con el código HTTP que le corresponde y una explicación en español de la causa (errores de base de datos, resoluciones con rango de numeración vacío, datos inválidos). Además, toda respuesta fallida queda registrada en storage/logs/laravel.log con la ruta, el usuario y los datos enviados (sin certificados ni contraseñas), para que soporte pueda ubicar el caso.
  • Adquirientes del exterior: la dirección en el XML y en el PDF usa municipio y departamento en texto libre (municipality_name, state_name). Si no se envían, los campos quedan vacíos en lugar de mostrar datos de otro registro.

Correcciones destacadas​

APIInterfaz
  • Evento RADIAN de reclamo (rechazo): la DIAN respondía AAH10 por los códigos del motivo; se restauraron los códigos 01 a 04 del anexo técnico.
  • Municipios: se corrigió el código del facturador para todos los municipios del catálogo, alineándolos con el facturador web.
  • Notas de ajuste de documento soporte: ya se guardan con el ambiente correcto.
  • Nómina electrónica: se corrigió el nombre del empleador en el XML.
  • Anulación de factura desde la interfaz: la nota crédito automática toma prefijo, número y fecha correctos y describe "Anulación de la factura" con el número anulado.
  • Extractor de documentos de compra: la DIAN cambió el formato de fechas de su catálogo (ahora solo acepta YYYY-MM-DD) y las consultas devolvían cero documentos sin error. El extractor ya envía el formato nuevo.
  • Envío de correo por API con copias (email_cc_list): corregido el error que impedía enviarlo.

Agosto 2026​

Mejoras en la API​

API
  • Nuevo endpoint GET /api/ubl2.1/config/certificate que devuelve el certificado .p12 de la empresa autenticada en base64, con su nombre y fecha de vencimiento. Útil para respaldos y para sincronizarlo con otros sistemas.
  • Ambiente por tipo de documento: los documentos equivalentes y la nómina se envían a la URL del ambiente de su propio tipo de documento, y la regeneración del AttachedDocument de notas y documento soporte consulta la URL del tipo correspondiente. Antes se usaba siempre la de factura, y una empresa con facturación en producción y nómina en habilitación (o al revés) obtenía errores de ambiente.
  • Nota de ajuste de nómina: los datos bancarios (bank_name, account_type, account_number) solo se exigen con medios de pago bancarios; en efectivo ya no son obligatorios aunque sea una nota de reemplazo.
  • Resoluciones con rango vacío: si la resolución registrada no tiene from/to válidos, la API lo indica con un mensaje claro en lugar de un error genérico de validación numérica.

Ajustes en las plantillas PDF​

Interfaz
  • Base AIU con el porcentaje calculado al lado del valor, en todas las plantillas de factura.
  • Las plantillas tipo ticket (3 y 7) ocultan la fila de IVA cuando el valor es cero.
  • Nuevo campo para mostrar los atributos del producto en las plantillas.

Compatibilidad con PostgreSQL​

Compatibilidad con PostgreSQL​

Instalación

La API ahora puede instalarse tanto sobre MySQL/MariaDB como sobre PostgreSQL. Si su infraestructura ya está montada sobre PostgreSQL, ya no necesita un servidor de base de datos adicional para operar la facturación electrónica.

La actualización incluye manuales de instalación paso a paso para ambos escenarios:

Scripts y manuales de instalación renovados​

Instalación

Se actualizó todo el proceso de instalación de la plataforma:

  • Los scripts de instalación con Docker ahora instalan el extractor de documentos de compra junto con la API, sin configuración manual adicional — tanto en la instalación de solo API como en la de API + facturador web.
  • Manuales de instalación versión 2026 actualizados: Linux Ubuntu 22.04/24.04 y Windows.
  • En instalaciones sobre servidor LAMP (Ubuntu 22.04/24.04), el ajuste de compatibilidad de los certificados digitales (.p12) con las versiones recientes de OpenSSL ahora se aplica automáticamente durante la instalación.

Más detalle en la sección Instalación del manual.

Julio 2026​

Extractor de documentos de compra disponible desde la API​

API

El Extractor de documentos de compra (lanzado en mayo para la interfaz) ahora también puede consumirse desde la API mediante nuevos endpoints, pensado para quienes integran la plataforma desde sus propios sistemas:

  • Autenticación con el token de la empresa: no es necesario enviar el certificado en cada llamada; se usa el que la empresa ya tiene configurado.
  • Dos modos de consumo: una llamada única que devuelve toda la información procesada al terminar, o modo asíncrono con consulta de avance, ideal para rangos de fechas grandes.
  • Permite extraer tanto los documentos recibidos (compras) como los enviados, y la respuesta entrega la información ya procesada: CUFE, emisor, totales, impuestos y detalle de ítems.
  • Documentación de integración incluida para conectar el extractor a una instalación existente de la API: despliegue e integración y API del extractor.

Eventos RADIAN indicando solo el CUFE​

Interfaz

Desde la interfaz ahora es posible registrar eventos RADIAN (acuse de recibo, recibo del bien, aceptación, etc.) de una factura recibida ingresando únicamente su CUFE. Ideal para gestionar eventos de documentos que no fueron emitidos desde la plataforma.

Plantillas PDF configurables por tipo de documento​

Interfaz

Cada empresa puede ahora asignar una plantilla gráfica distinta para cada tipo de documento: factura de venta, documento equivalente, nómina electrónica y documento soporte, todo desde la sección Documentos Electrónicos de la interfaz. Las notas crédito y débito usan automáticamente la plantilla configurada para facturas.

Proceso de habilitación de empresas más guiado​

Interfaz

Mejoras en el asistente de creación de empresas desde la interfaz:

  • Creación de resoluciones directamente desde la interfaz.
  • Envío del set de pruebas de habilitación incluyendo nota crédito.
  • Vista de JSON de ejemplo para facilitar la integración.
  • Ejecución automática de los ajustes técnicos de habilitación (scripts URN), que antes requerían intervención manual.

Junio 2026​

Módulo de copias de seguridad​

Interfaz

Nuevo módulo de backups en el panel de administración: los respaldos se generan en segundo plano sin afectar la operación, se administran desde la interfaz y el sistema depura automáticamente los archivos antiguos para no agotar el espacio en disco.

Monitoreo de recursos del servidor​

InterfazInstalación

Nuevo sistema de monitoreo (contenedor independiente) que registra la saturación del servidor, las peticiones lentas y el consumo de recursos por empresa. Permite diagnosticar problemas de rendimiento y dimensionar el servidor con datos reales.

Estado del envío de correos al adquiriente​

APIInterfaz

Ahora puede saber si el correo con la factura llegó, falló o está pendiente:

  • Indicador visual del estado del envío en la interfaz.
  • La respuesta de la API al emitir el documento incluye el resultado del envío del correo.
  • Cada empresa puede configurar el nombre y la dirección del remitente con que salen sus correos.

Buscador y filtros en los documentos de cada empresa​

Interfaz

El listado de documentos de la empresa incorpora una barra de búsqueda con filtros (facturas, nómina, documentos recibidos y eventos), con paginación mejorada. Encontrar un documento específico ahora toma segundos.

Regeneración de AttachedDocument​

API

Nuevo endpoint de la API para regenerar el AttachedDocument (el XML que empaqueta la factura con la respuesta de la DIAN) de un documento ya emitido. Útil cuando el adjunto original no se generó correctamente, sin necesidad de reenviar el documento.

Sector salud: facturación sin contrato​

API

Soporte para operaciones del sector salud sin contrato asociado, con los nuevos campos requeridos en la información adicional. En julio se complementó con la posibilidad de informar varios pacientes en un mismo documento (validación RIPS).

Mayo 2026​

Extractor de documentos de compra​

InterfazAPI

Lanzamiento del Extractor de documentos de compra: un módulo que se conecta al catálogo de la DIAN y descarga automáticamente los documentos electrónicos de la empresa en un rango de fechas — tanto los recibidos (facturas de compra de sus proveedores) como los enviados — extrayendo su información completa: CUFE, emisor, fechas, totales, impuestos y detalle de ítems. Los documentos recibidos pueden además registrarse en eventos RADIAN.

Disponible desde la interfaz de la plataforma y también vía API (habilitado en julio): ver documentación de la API del extractor.