Generar el XML sin reportarlo

Construye y firma el documento sin enviarlo a la DIAN. No gasta consecutivos.

PATCH /api/xmlFE

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 Facturación electrónica, donde se explica qué documentos existen, cómo se arma el JSON y qué valida el servidor antes de que ejecutes nada.

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

Es por donde conviene empezar: no gasta consecutivos y no deja nada registrado en la DIAN, así que se puede repetir cuantas veces haga falta para comparar el XML propio con el que arma el PT. Atiende todos los tipos del grupo — el tddocumentoelectronico 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
`tddocumentoelectronico`*	`string`	Tipo de documento electrónico. Es el campo que decide qué valida la DIAN y con qué resolución se numera. Ver los 8 valores admitidos `01` · Factura electrónica de venta `02` · Factura electrónica de venta - exportación `03` · Instrumento electrónico de transmisión `04` · Factura electrónica de venta - tipo 04 `05` · Documento soporte en adquisiciones a no obligados a facturar `91` · Nota crédito `92` · Nota débito `95` · Nota de ajuste del documento soporte
`tdoperacionfe`*	`string`	Tipo de operación. Define que bloques adicionales exige la DIAN dentro de cada item. Ejemplo:`10` Ver los 7 valores admitidos `09` · AIU — Administración, Imprevistos y Utilidad `10` · Estándar — venta normal de bienes y servicios `11` · Mandatos — exige `items[].mandante` `12` · Transporte — exige `items[].datostransporte` `14` · Actos notariales `15` · Compra de divisas `16` · Venta de divisas
`numerodocumento`*	`string`	Número completo del documento: prefijo de la resolución más consecutivo. Aquí no se admite `<auto>`, porque esta función no numera: el consecutivo lo pone el desarrollador. Ejemplo:`SETP990000001`
`fechadocumento`	`date-time`	Fecha y hora de emisión. 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 —una fecha escrita a mano envejece y termina fuera de la vigencia de la resolución—. Si la envías, va en ISO 8601 con zona (`2026-08-06T10:30:00-05:00`); la DIAN rechaza la fecha futura y la que caiga fuera de esa vigencia. Ejemplo:`2026-08-06T10:30:00-05:00`
`qdecimales`	`number`	Decimales con los que se calculan los totales y el UUID. Por defecto 2, que es con lo que van los ejemplos: solo hace falta enviarlo para trabajar con otra precisión. Ejemplo:`2`
`emisor`*	TTercero	Quien emite el documento. A diferencia del envío, aquí su identidad no se reemplaza: el XML se construye con el emisor que llegue.
`emisor.ubicacion`*	TUbicacion	Dirección comercial. Va con el código de municipio (`17001`) y el de departamento (`17`); basta el código, porque el PT completa los dos nombres. De qué listado salen se explica en el concepto del grupo.
`emisor.ubicacionfiscal`	TUbicacion	Dirección fiscal. La DIAN la exige en la factura estándar; en documento soporte y nota de ajuste se omite. Si no se envía se asume igual a `ubicacion`.
`emisor.tdresponsabilidadfiscales`*	`Array<string>`	Responsabilidades fiscales del emisor según el RUT. Ver los 5 valores admitidos `O-13` · Gran contribuyente `O-15` · Autorretenedor `O-23` · Agente de retención de IVA `O-47` · Regimen simple de tributacion `R-99-PN` · No aplica / otros
`emisor.tributoresponsable`*	`string`	Tributo del que el emisor es responsable. Ver los 4 valores admitidos `01` · IVA `02` · INC `ZA` · IVA e INC `ZZ` · No aplica
`emisor.contacto.email`*	`string`	Correo del emisor. Es obligatorio en facturación electrónica: es a donde la DIAN notifica.
`receptor`*	TTercero	A quien se le emite. Misma estructura del emisor y, como el emisor, tampoco se reemplaza.
`resolucion`*	TResolucion	Resolución de numeración con la que se emite. Es obligatoria: esta función no registra resolución, y la verificación exige al menos el `prefijo`. Las facturas exigen además `numeroresolucion`, `fechainicial` y `fechafinal` —en ISO 8601— y la `clavetecnica` con la que se calcula el CUFE.
`items`*	Array<TItem>	Líneas del documento. Al menos una, con `cantidad` mayor que cero.
`items[].nombre`*	`Array<string>`	Descripción de la línea. Es un arreglo porque la DIAN admite varias líneas de descripción.
`items[].unidad`*	`string`	Unidad de medida en código UNECE. Ejemplo:`EA` Ver los 6 valores admitidos `EA` · Cada / unidad `KGM` · Kilogramo `LTR` · Litro `MTR` · Metro `HUR` · Hora `NIU` · Número de unidades internacionales
`items[].tributos`	Array<TImpuesto>	Impuestos y retenciones de la línea. Cada uno con `clase`, `valorbase` y `valor`. Ver los 12 valores admitidos `01` · IVA `02` · IC — Impuesto al consumo `03` · ICA `04` · INC `05` · ReteIVA `06` · ReteRenta `07` · ReteICA `21` · Timbre — exige `precio` `22` · INC Bolsas — exige `precio` `34` · IBUA `35` · ICUI `ZZ` · Otro tributo
`resumentributos`*	Array<TImpuesto>	Consolidado de tributos del documento. La DIAN valida que coincida con la suma de los tributos de los items.
`mediosdepago`*	Array<TMedioPago>	Como se paga el documento. `fechapago` es obligatoria cuando `tdformapago` es crédito, y va en ISO 8601 como toda fecha del documento. `tdmediopago` es opcional: si no llega, o llega con un código que no está en el catálogo, el PT asume `1` — Instrumento no definido. Los 76 códigos del catálogo están en la ficha del objeto `TMedioPago`. Ver los 6 valores admitidos `1` · tdformapago — Contado `2` · tdformapago — Credito `10` · tdmediopago — Efectivo `42` · tdmediopago — Consignacion bancaria `49` · tdmediopago — Tarjeta debito `ZZZ` · tdmediopago — Otro
`descuentoscargos`	Array<TDescuentoCargo>	Descuentos y recargos a nivel de documento. Si no se indica `tddescuento`, el PT lo asigna según corresponda.
`anticipos`	Array<TAnticipo>	Anticipos recibidos. Su total se resta del valor a pagar.
`moneda`	TMoneda	Divisa distinta del peso colombiano, con su tasa de cambio y la fecha de la tasa. Si se envía, el XML incluye los totales también en COP.
`totalapagar`	`number`	Total del documento. Si no se envía, el PT lo calcula desde los items, los tributos, los descuentos y los anticipos.
`notas`	`Array<string>`	Observaciones libres que se imprimen en la representación grafica.

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 — 93 escenarios

Factura gravada al 19% con numeración y resolución explícitas, que es lo que esta función exige. Reemplaza la clave técnica por la de tu resolución para que el CUFE sea el real.

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

JSON válido

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

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 documento, con Content-Type: application/xml y Content-Disposition: inline. 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; en respuesta.notificaciones, las advertencias que no impiden la generación.
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 que corregir.
400 Reglas AB05, AB05a, AB07, AB08 y AB10a — resolución incompleta

Esta función no registra resolución: hay que enviarla completa. AB05 es la resolución ausente, AB10a el prefijo, AB05a el número, AB07 y AB08 las fechas de vigencia, y AB05_1 la clave técnica que exigen las facturas. En el envío no aparecen porque ahí el sandbox pone su propia resolución.
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. El emisor, el receptor, la resolución y el consecutivo son los que se envien: es la diferencia de fondo con POST /api/DocumentoFE, que fuerza la identidad de las partes y numera con su propia resolución.
Los ejemplos de la emisión no sirven aquí tal cual: llevan numerodocumento en <auto> y su bloque resolucion trae marcado como <Lo sobrescribe el sandbox> todo lo que el envío le pone —el número, el prefijo y la clave técnica en una factura o un documento soporte; solo el prefijo en una nota, que no consume resolución—. Aquí no los pone nadie: reemplázalos por los de tu resolución, o usa los dos ejemplos propios de esta ficha, que ya vienen completos.
La clavetecnica de la resolución interviene en el cálculo del CUFE. Con una clave distinta de la real el XML se genera igual, pero su CUFE no coincidira con el del documento que se emita después.
En producción la ruta es una sola, PATCH /api/xml. El tddocumentoelectronico del cuerpo es el que decide qué se genera, igual que aquí.
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.
El XML se firma con las credenciales de habilitación del sandbox, comunes a todos los desarrolladores. En producción se firma con las del emisor real, que administra el Proveedor Tecnológico.