Generar el XML sin reportarlo

Construye y firma el ApplicationResponse de un evento DIAN, sin enviarlo a la DIAN.

PATCH /api/xmlDE

Es la ruta de la función, y no cambia entre ambientes. La URL base con la que la ejecutas aquí es la del sandbox. Es la URL del sandbox y no corresponde a la etapa productiva de la integración. La URL base de producción se te entrega al adquirir el servicio.

¿Es tu primer contacto con esta parte de la plataforma? Empieza por Eventos de la DIAN, donde se explica qué documentos existen, cómo se arma el JSON y qué valida el servidor antes de que ejecutes nada.

Genera el evento firmado y se detiene antes de reportarlo. La respuesta es el XML, con Content-Type: application/xml.

En este grupo es donde más se nota la diferencia: la DIAN no admite dos veces el mismo evento sobre la misma factura, de modo que cada envío que sale mal quema esa factura para ese evento. Aquí no se reporta nada, así que se puede repetir cuantas veces haga falta con el mismo CUFE. Atiende los cinco eventos del ciclo — el tdevento decide cuál se genera.

Cómo resuelve el sandbox esta función

Generación de XML sin reportar

Recorre el mismo camino de la emisión pero se detiene antes de la DIAN. Con el documento en JSON calcula el UUID que tendría —CUFE, CUDE o CUDS— y lo valida contra las reglas: si alguna se incumple responde 400 con una entrada por regla, cada una con su código y su mensaje. Si las cumple, construye el documento electrónico, lo firma y devuelve el XML como application/xml, no como JSON: la respuesta es el documento mismo y no un objeto que lo envuelva. El documento no se reporta, así que no gasta consecutivos y la prueba se puede repetir sin costo. A diferencia de la emisión, aquí solo se fuerza el ambiente: no se reemplazan emisor, receptor ni resolución, y la contrapartida es que el CUFE obtenido es el real solo si la resolución y su clave técnica son las verdaderas del emisor.

Desliza el diagrama para verlo completo.

Ver la fuente Mermaid del diagrama

flowchart TD
    A(["El documento llega en JSON"]) --> D["Calcula el UUID del documento<br/>CUFE · CUDE · CUDS"]
    D --> F{"¿Cumple las reglas?"}
    F -- No --> G(["400 · una entrada por regla incumplida,<br/>con su código DIAN y su código InSoft"])
    F -- Sí --> H["Construye el documento electrónico<br/>y lo firma"]
    H --> J(["200 · el XML firmado, no se reporta a la DIAN<br/>application/xml"])

Datos que recibe

Encabezado

Dato Tipo Descripción

Dato	Tipo	Descripción
`Authorization`*	`string`	Credencial de la petición, con el prefijo `Bearer`. En el sandbox la pone el portal por ti y la renueva antes de cada ejecución; en producción la controlas tú, con el JWT que genera tu integración a partir de sus credenciales — ver Credenciales y JWT. Ejemplo:`Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6...`

Authorization*

string

Credencial de la petición, con el prefijo Bearer. En el sandbox la pone el portal por ti y la renueva antes de cada ejecución; en producción la controlas tú, con el JWT que genera tu integración a partir de sus credenciales — ver Credenciales y JWT.

Ejemplo:Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6...

Cuerpo

Dato	Tipo	Descripción
`tdevento`*	`string`	Evento que se construye. Es el campo que decide qué se valida y qué nodos lleva el `ApplicationResponse`. Ver los 5 valores admitidos `030` · Acuse de recibo de la factura electrónica de venta `031` · Reclamo de la factura electrónica de venta `032` · Recibo del bien o prestación del servicio `033` · Aceptación expresa `034` · Aceptación tácita
`docreferencia`*	TDocumentoElectronico	Factura sobre la que aplica el evento, con su `numerodocumento`, su `fechadocumento` —en ISO 8601— y su `uuid` (CUFE). Esta fecha sí la pones tú: identifica la factura, no el evento.
`numerodocumento`*	`string`	Consecutivo del evento dentro de la numeración propia de quien lo emite. No requiere resolución. Ejemplo:`1`
`fechadocumento`	`date-time`	Fecha y hora en que ocurre el evento. Es opcional: si no la envías, el PT le asigna la de ahora, el momento en que recibe el documento, y es lo que hacen los ejemplos. Si la envías, va en ISO 8601 con zona (`2026-08-07T08:00:00-05:00`) y no puede ser anterior a la de la factura. Ejemplo:`2026-08-07T08:00:00-05:00`
`emisor`*	TTercero	Quien emite el evento. A diferencia del envío, aquí su identidad no se reemplaza: el XML se construye con el tercero que llegue.
`receptor`*	TTercero	Quien recibe el evento. Como el emisor, tampoco se reemplaza.
`usuario`*	TUsuario	Persona natural que suscribe el evento. Sale en el bloque `IssuerParty/Person` del XML.

Lo que el sandbox fuerza

El sandbox firma con las credenciales de habilitación, compartidas por todos los desarrolladores. Lo que envíes en estos campos no se usa: se sustituye antes de construir el documento. Todo lo demás viaja tal como lo dejes.

tdambiente
2 — Pruebas (habilitación)
El XML se firma con las credenciales de habilitación del sandbox. Un documento marcado como de producción firmado con esas credenciales sería inválido, de modo que el ambiente se fuerza antes de construirlo.

Ejecutar la función

Ambiente de habilitación de la DIAN · el XML se firma pero no se reporta, no gasta consecutivos

Lo que se envía

Ejemplo — 15 escenarios

Caso base del acuse de recibo, con todos los datos diligenciados. Por aquí conviene empezar.

Documento que se envía — editalo para armar tu caso de prueba

JSON válido

Se enviara PATCH https://proveedortecnologico-sandbox.azurewebsites.net/api/xmlDE

Es la URL del sandbox y no corresponde a la etapa productiva de la integración. La URL base de producción se te entrega al adquirir el servicio. Lo que si es igual en los dos es la ruta.

Respuesta

Aquí queda tu ejecución: la ruta que viajó, el cuerpo que enviaste, el código con el que respondió el sandbox y el tiempo discriminado. Un error también queda: es lo que se necesita junto al cuerpo que lo produjo.

Exportar a Postman

Descarga esta función como colección de Postman, con los valores que tienes ahora en la barra y tu credencial vigente: se importa y se envía sin configurar nada.

Respuestas

200 El cuerpo es el XML firmado del ApplicationResponse, con Content-Type: application/xml. No viene envuelto en la estructura estándar del PT.
400 El documento no paso la verificación. En respuesta.errores viaja un elemento por regla incumplida, con codigodian, codigoinsoft y mensaje.
401 La credencial no llegó, ya venció, o la cuenta no tiene perfil registrado en el sandbox. En producción es además el código con el que se rechaza un emisor que la credencial no tiene autorizado — ver Credenciales y JWT.
500 Falla al firmar el documento.

Errores frecuentes

400 El documento electrónico no ha pasado el proceso de verificación

Es la respuesta de toda regla incumplida. A diferencia del envío, aquí el detalle viene desglosado: cada error trae el código de la regla de la DIAN, el código interno de InSoft y la descripción de qué corregir.
400 El motivo del reclamo es obligatorio

Se envió tdevento en 031 sin tdreclamo. La verificación lo detecta aquí, antes de gastar el evento en la DIAN.
401 El desarrollador autenticado no tiene un perfil registrado en el sandbox

La cuenta se autenticó pero nunca completó el registro de desarrollador. Se resuelve diligenciando el perfil desde el portal.

Ten en cuenta

Esta función no reemplaza nada del documento salvo el ambiente, a diferencia del envío, que sustituye la identidad de emisor y receptor por la de la empresa de pruebas.
Como no reporta nada, el CUFE de docreferencia no tiene que existir en la DIAN para poder generar el XML. Para el envío sí tiene que existir, y en habilitación solo existen las facturas emitidas desde el propio sandbox.
El XML se firma con las credenciales de habilitación del sandbox, comunes a todos los desarrolladores.
En producción la ruta es una sola, PATCH /api/xml, y fuerza el tipo de documento a 96.
El XML se genera en UTF-8, y así lo declara el propio documento en su primera línea. Léelo y guárdalo con esa codificación: interpretado con otra, cada tilde y cada ñ se convierten en dos caracteres raros y la firma deja de validar.