---
title: "Emisión paso a paso"
description: ""
type: "academy"
category: "module"
tags: []
authors: [Anonymous]
date: "2026-11-05"
last_update: "2026-11-05"
time_minutes: 41
draft: false
unlisted: false
url: "https://www.apigateway.cl/academy/emision-de-dte/emision"
---

# Emisión paso a paso




---

## Paso 1: Construir el DTE (obligatorio)

Cómo armar los datos del documento y transformarlos en un DTE timbrado y firmado con la operación builder/build, y qué guardar de la respuesta.

# Paso 1: Construir el DTE (obligatorio)

Todo empieza con los datos de la venta. Tu sistema los arma en JSON y la operación **`builder/build`** los transforma en el XML oficial del documento. Es la misma operación para todos los documentos: facturas, notas, guías y boletas. En una sola llamada la API:

1. **Normaliza** los datos: completa campos por defecto, numera las líneas y calcula los totales.
2. **Timbra** el documento con la llave del CAF (genera el timbre electrónico, TED).
3. **Firma** el XML con tu certificado digital.

## Los datos del documento

El JSON sigue **la misma estructura y los mismos nombres de campos que el XML oficial del SII**. Por eso los nombres están en español abreviado (`RznSoc`, `NmbItem`, `PrcItem`): son los del SII.

```json
{
    "Encabezado": {
        "IdDoc":    { "...": "qué documento es" },
        "Emisor":   { "...": "quién vende" },
        "Receptor": { "...": "quién compra" },
        "Totales":  { "...": "montos: no los envíes, los calcula la API" }
    },
    "Detalle":      [ { "...": "un objeto por producto o servicio" } ],
    "DscRcgGlobal": [ { "...": "descuentos o recargos globales (opcional)" } ],
    "Referencia":   [ { "...": "documentos relacionados (opcional)" } ]
}
```

No envíes los totales: la API los calcula. Antes de construir, reserva en tu sistema el folio que vas a usar, para que nunca se repita.

El SII define muchos más campos: formas de pago, descuentos, referencias, datos de transporte, impuestos adicionales y otros. La descripción de cada uno, su largo máximo y en qué documentos es obligatorio están en la documentación oficial del SII:

**Documentos tributarios electrónicos (no boletas):**

- [Descripción del formato de DTE](https://www.sii.cl/factura_electronica/factura_mercado/formato_dte_202602.pdf)
- [Diagrama del XML de DTE](https://www.sii.cl/factura_electronica/factura_mercado/diagrama_dte.zip)

**Boletas:**

- [Descripción del formato de boletas](https://www.sii.cl/factura_electronica/factura_mercado/boletas_elec_0720_3.pdf)
- [Diagrama del XML de boletas](https://www.sii.cl/factura_electronica/factura_mercado/diag_boleta_0920.zip)

Para ver cómo se usan, revisa los ejemplos de la API con la operación `examples/get` (ver [Tu primera llamada](https://www.apigateway.cl/academy/emision-de-dte/preparacion/tu-primera-llamada)) y los [casos prácticos](https://www.apigateway.cl/academy/emision-de-dte/casos-practicos).

## La solicitud

```
POST https://app.apigateway.cl/api/v2/libredte/billing/document/builder/build
```

La llamada es la misma para todos los documentos, incluidas las boletas; cambian los datos del documento (`parsedData`) y el CAF.

La "bolsa" (`bag`) agrupa todo lo que se necesita para construir el documento:

| Campo | Qué es |
|-------|--------|
| `parsedData` | Los datos del documento, en JSON (ver [Los datos del documento](#los-datos-del-documento)). |
| `caf` | El XML del CAF en base64. Debe ser del mismo tipo de documento: de facturas para una factura, de boletas para una boleta. |
| `certificate` | El certificado digital (ver [El certificado digital](https://www.apigateway.cl/academy/emision-de-dte/preparacion/certificado-digital)). |

**La fecha de emisión** va en `IdDoc.FchEmis` (`AAAA-MM-DD`). Si no la envías, la API usa la fecha del día. Guárdala junto al documento: la necesitarás para corregirlo con una nota de crédito (`FchRef`) y para verificarlo en el SII. También la encuentras en la respuesta, en `data.document.Encabezado.IdDoc.FchEmis`.

Estos son los ejemplos de cada caso:

### 1.1. Facturas, notas y guías

```json
{
    "parameters": {
        "bag": {
            "parsedData": {
                "Encabezado": {
                    "IdDoc": { "TipoDTE": 33, "Folio": 1, "FmaPago": 1 },
                    "Emisor": {
                        "RUTEmisor": "88888888-8",
                        "RznSoc": "Mi Empresa SpA",
                        "GiroEmis": "Venta de software",
                        "Acteco": 620100,
                        "DirOrigen": "Av. Siempre Viva 742",
                        "CmnaOrigen": "Providencia"
                    },
                    "Receptor": {
                        "RUTRecep": "77777777-7",
                        "RznSocRecep": "Cliente Ejemplo Ltda.",
                        "GiroRecep": "Comercio",
                        "DirRecep": "Calle Falsa 123",
                        "CmnaRecep": "Santiago"
                    }
                },
                "Detalle": [
                    { "NmbItem": "Servicio de desarrollo", "QtyItem": 1, "PrcItem": 100000 }
                ]
            },
            "caf": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8QVVU...",
            "certificate": {
                "certificate": "-----BEGIN CERTIFICATE-----\nMIIG...\n-----END CERTIFICATE-----",
                "privateKey": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----"
            }
        }
    }
}
```

El precio (`PrcItem`) va **neto**. No hay totales: la API calcula neto $100.000, IVA $19.000 y total $119.000.

### 1.2. Boletas

```json
{
    "parameters": {
        "bag": {
            "parsedData": {
                "Encabezado": {
                    "IdDoc": { "TipoDTE": 39, "Folio": 1 },
                    "Emisor": {
                        "RUTEmisor": "88888888-8",
                        "RznSoc": "Mi Empresa SpA",
                        "GiroEmis": "Venta de artículos de computación",
                        "DirOrigen": "Av. Siempre Viva 742",
                        "CmnaOrigen": "Providencia"
                    },
                    "Receptor": {
                        "RUTRecep": "66666666-6",
                        "RznSocRecep": "Cliente final",
                        "DirRecep": "Santiago",
                        "CmnaRecep": "Santiago"
                    }
                },
                "Detalle": [
                    { "NmbItem": "Mouse inalámbrico", "QtyItem": 2, "PrcItem": 11900 }
                ]
            },
            "caf": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8QVVU...",
            "certificate": {
                "certificate": "-----BEGIN CERTIFICATE-----\nMIIG...\n-----END CERTIFICATE-----",
                "privateKey": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----"
            }
        }
    }
}
```

La API calcula un total de $23.800, del que $20.000 es neto y $3.800 es IVA. Lo que cambia respecto de una factura:

| Dato | En una boleta |
|------|---------------|
| `TipoDTE` | `39`, o `41` si es una boleta exenta. |
| `PrcItem` | **Con IVA incluido.** |
| Receptor | Opcional. Si el cliente no da su RUT, usa `66666666-6`. |
| `FmaPago`, `Acteco`, `GiroRecep` | No se usan. |
| `RznSoc`, `GiroEmis` | Se envían igual que en una factura. En el XML de la boleta la API los escribe como `RznSocEmisor` y `GiroEmisor`, los nombres que usa el SII. |
| `caf` | Un CAF de boletas (`39`, o `41` para la exenta). |

En una **boleta exenta** (`41`), marca cada ítem con `IndExe: 1`: la API calcula `MntExe` con el total, sin IVA.

## Qué se obtiene según lo que envíes

| Envías | Obtienes | Sirve para |
|--------|----------|------------|
| Solo `parsedData` | Un **borrador**, sin timbre ni firma | Previsualizar los totales o el PDF de una cotización |
| `parsedData` + `caf` | Un documento **timbrado**, sin firma | (Poco uso práctico) |
| `parsedData` + `caf` + `certificate` | Un documento **timbrado y firmado** | **Emitir**: es lo que se envía al SII |

Para emitir, envía siempre los tres.

## La respuesta

Esta es la respuesta para la factura del ejemplo, construida con un CAF del ambiente de certificación. Se muestran los campos que usarás; la tabla de abajo describe todos. Los valores largos (XML en base64, llaves y certificados) están acortados con `...`:

```json
{
    "data": {
        "document_id": "88888888-8_T033F000000001",
        "document_xml": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0i...",
        "document": {
            "Encabezado": {
                "IdDoc": {
                    "TipoDTE": 33,
                    "Folio": 1,
                    "FchEmis": "2026-10-29",
                    "TpoTranVenta": 1,
                    "FmaPago": 1
                },
                "Emisor": {
                    "RUTEmisor": "88888888-8",
                    "RznSoc": "Mi Empresa SpA",
                    "GiroEmis": "Venta de software",
                    "Acteco": 620100,
                    "DirOrigen": "Av. Siempre Viva 742",
                    "CmnaOrigen": "Providencia"
                },
                "Receptor": {
                    "RUTRecep": "77777777-7",
                    "RznSocRecep": "Cliente Ejemplo Ltda.",
                    "GiroRecep": "Comercio",
                    "DirRecep": "Calle Falsa 123",
                    "CmnaRecep": "Santiago"
                },
                "Totales": {
                    "MntNeto": 100000,
                    "TasaIVA": 19,
                    "IVA": 19000,
                    "MntTotal": 119000
                }
            },
            "Detalle": [
                {
                    "NroLinDet": 1,
                    "NmbItem": "Servicio de desarrollo",
                    "QtyItem": 1,
                    "PrcItem": 100000,
                    "MontoItem": 100000
                }
            ]
        },
        "document_normalized": {
            "Encabezado": {
                "Totales": {
                    "MntNeto": 100000,
                    "MntExe": null,
                    "TasaIVA": 19,
                    "IVA": 19000,
                    "ImptoReten": null,
                    "CredEC": null,
                    "MntTotal": 119000,
                    "TpoMoneda": null
                }
            },
            "...": "todos los campos del formato"
        },
        "document_type": {
            "codigo": 33,
            "nombre": "Factura electrónica",
            "...": "..."
        },
        "certificate": {
            "id": "11222333-9",
            "name": "Daniel Bot",
            "...": "...",
            "pkey": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----"
        },
        "caf": {
            "id": "CAF33D1H100",
            "...": "...",
            "privateKey": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----"
        },
        "...": "document_parsed, document_stamp, timbre, document_auth, document_extra, emisor, receptor y options"
    }
}
```

| Campo | Qué es | ¿Guardarlo? |
|-------|--------|-------------|
| `document_xml` | **El XML del DTE timbrado y firmado, en base64.** Es el documento con validez tributaria. | Sí, siempre |
| `document_id` | Identificador del documento: emisor, tipo y folio. | Sí |
| `document` | Los datos del documento tal como quedaron en el XML, solo con los campos que tienen valor. | Opcional |
| `document_normalized` | Los mismos datos con todos los campos del formato; los que no se usan vienen en `null`. Incluye los totales calculados. | Opcional |
| `document_parsed` | Los datos tal como los enviaste en `parsedData`. | No |
| `document_type` | Datos del tipo de documento: nombre, si es cedible, si es exento, etc. | No |
| `document_stamp` | El timbre electrónico (TED) en XML, en base64. Ya está dentro de `document_xml`. | No |
| `timbre` | El mismo timbre electrónico, en formato JSON. | No |
| `document_auth` | La resolución del emisor, si la indicaste. | No |
| `document_extra` | Datos adicionales del documento, si los hay. | No |
| `emisor`, `receptor` | Los datos del emisor y del receptor que usó la API. | No |
| `certificate` | Los datos del certificado usado, **incluida su llave privada** (`pkey`). | **No** |
| `caf` | Los datos del CAF usado, **incluida su llave privada** (`privateKey`). | **No** |
| `options` | Las opciones que usó cada etapa de la construcción. | No |

> [!WARNING] Guarda solo lo necesario
>
> La respuesta incluye los datos del certificado y del CAF que se usaron, con sus llaves. No guardes la respuesta completa en tu base de datos ni en tus logs: guarda el `document_xml`, el `document_id` y, si los necesitas, los totales.

Decodificado, `document_xml` se ve así (resumido):

```xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<DTE xmlns="http://www.sii.cl/SiiDte" version="1.0">
  <Documento ID="LibreDTE_88888888-8_T033F000000000001">
    <Encabezado>
      <IdDoc><TipoDTE>33</TipoDTE><Folio>1</Folio><FchEmis>2026-10-29</FchEmis></IdDoc>
      <Emisor>...</Emisor>
      <Receptor>...</Receptor>
      <Totales><MntNeto>100000</MntNeto><TasaIVA>19</TasaIVA><IVA>19000</IVA><MntTotal>119000</MntTotal></Totales>
    </Encabezado>
    <Detalle>...</Detalle>
    <TED version="1.0">...</TED>            <!-- timbre electrónico -->
    <TmstFirma>2026-10-29T16:57:50</TmstFirma>
  </Documento>
  <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">...</Signature>  <!-- firma -->
</DTE>
```

En una **boleta**, la respuesta tiene los mismos campos. `document_type` trae el código `39` ("Boleta electrónica") y el encabezado del XML usa los nombres de las boletas:

```xml
<IdDoc><TipoDTE>39</TipoDTE><Folio>1</Folio><FchEmis>2026-11-04</FchEmis><IndServicio>3</IndServicio></IdDoc>
<Emisor><RUTEmisor>88888888-8</RUTEmisor><RznSocEmisor>Mi Empresa SpA</RznSocEmisor><GiroEmisor>...</GiroEmisor>...</Emisor>
<Totales><MntNeto>20000</MntNeto><IVA>3800</IVA><MntTotal>23800</MntTotal></Totales>
```

`IndServicio` indica el tipo de venta; si no lo envías, la API pone `3` (venta de bienes y servicios).

> [!INFO] El XML no se modifica
>
> Una vez firmado, el XML no se puede tocar: cualquier cambio, aunque sea un espacio, invalida la firma. Guarda el base64 tal como llega, o decodifícalo a bytes sin convertir la codificación (es ISO-8859-1, no UTF-8).

## Errores frecuentes en este paso

| Mensaje (`detail`) | Causa | Solución |
|--------------------|-------|----------|
| `El XPath "//Encabezado/IdDoc/Folio" ... es obligatorio: no coincidió con ningún nodo.` | Falta `IdDoc.Folio`. | Asigna el folio desde tu control de folios. |
| `El folio N del documento ... no está disponible en el rango del CAF ...` | El folio no está dentro del CAF enviado. | Usa un folio del rango, o el CAF que corresponde a ese folio. |
| `El CAF ... fue autorizado al emisor ..., pero el documento ... es del emisor ...` | El CAF es de otra empresa. | Usa un CAF solicitado por la empresa que emite el documento. |
| `El CAF ... es del tipo de documento ..., pero el documento ... es del tipo ...` | El CAF es de otro tipo de documento, por ejemplo uno de facturas (`33`) para una boleta (`39`). | Usa el CAF del mismo tipo que el documento. |
| `The verification digit of the RUT ... is incorrect.` | Un RUT tiene mal el dígito verificador. | Valida los RUT en tu sistema antes de emitir. |
| `Falta incluir documento de referencia.` | Es una nota de crédito o débito sin `Referencia`. | Agrega la referencia al documento que corrige. |
| `No se encontró un deserializador capaz de construir una instancia de ...CafInterface ... requiere datos codificados en base64 válido.` | El `caf` no viene en base64 válido. | Codifica el XML del CAF en base64, en una línea. |
| `Se requieren los datos del certificado ...` | El certificado viene incompleto. | Envía `certificate` + `privateKey` (PEM), o `data` + `password` (`.p12`). |

> [!WARNING] Un CAF por emisor y por tipo de documento
>
> El CAF debe ser del **mismo emisor** y del **mismo tipo de documento**: una boleta (`39`) se timbra con un CAF de boletas, no con uno de facturas. Si no coinciden, la API rechaza la construcción con uno de los dos errores de la tabla.


    
---

## Paso 2: Validar antes de enviar (opcional)

Cómo revisar el esquema, los datos y la firma de un DTE antes de enviarlo al SII.

# Paso 2: Validar antes de enviar (opcional)

Este paso es opcional, pero muy recomendable mientras desarrollas: detecta en segundos los errores que el SII te diría recién al procesar el envío. Hay tres validaciones, y las tres reciben el mismo dato: el XML que construiste en el paso 1.

Las validaciones son **las mismas para todos los documentos, incluidas las boletas**: la API reconoce el tipo de documento y, si es una boleta, la revisa con el esquema de boletas del SII.

| Operación | Qué revisa |
|-----------|------------|
| `billing/document/validator/validateSchema` | Que el XML cumpla el **esquema oficial del SII** (campos, tipos de datos, largos, orden). |
| `billing/document/validator/validate` | Que los **datos** del documento sean coherentes (por ejemplo, que una nota tenga referencia). |
| `billing/document/validator/validateSignature` | Que la **firma** del XML sea válida. |

## Qué dato usar del paso 1

De la respuesta de [`builder/build`](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-1-construir-el-dte#la-respuesta) solo necesitas el campo **`document_xml`**:

```json
{
    "data": {
        "document_id": "88888888-8_T033F000000001",
        "document_xml": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8RFRF...",
        "...": "los demás campos de la respuesta"
    }
}
```

Copia ese valor **tal cual**, en base64 y sin decodificarlo, en el parámetro `source` de cada validación:

```json
{
    "parameters": {
        "source": "<el document_xml del paso 1>"
    }
}
```

> [!WARNING] Valida el mismo XML que vas a enviar
>
> No vuelvas a construir el documento para validarlo: cada construcción genera un XML con otra firma. Valida el `document_xml` que guardaste, que es el mismo que usarás en el [paso 3](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-3-armar-el-sobre).

## Validar el esquema

```bash
curl -X POST https://app.apigateway.cl/api/v2/libredte/billing/document/validator/validateSchema \
  -H "Authorization: Token $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"parameters": {"source": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8RFRF..."}}'
```

Si el XML es válido, la respuesta es `200` con el documento leído como JSON dentro de `data`. Si no lo es, es un `422` con el motivo en `detail`.

## Validar los datos

```bash
curl -X POST https://app.apigateway.cl/api/v2/libredte/billing/document/validator/validate \
  -H "Authorization: Token $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"parameters": {"source": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8RFRF..."}}'
```

Si no hay problemas, la respuesta es `{"data": null}` con código `200`.

## Validar la firma

```bash
curl -X POST https://app.apigateway.cl/api/v2/libredte/billing/document/validator/validateSignature \
  -H "Authorization: Token $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"parameters": {"source": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8RFRF..."}}'
```

La respuesta siempre es `200`, y el resultado está en `data.valid`. Si la firma es válida, `valid` es `true` y `signature` trae los datos de la firma, incluido quién firmó (`signer`):

```json
{
    "data": {
        "valid": true,
        "error": null,
        "signature": {
            "reference": "LibreDTE_88888888-8_T033F000000000001",
            "digestValue": "YMnSHe2YViJQh/GdUuLB66wOM3M=",
            "signer": {
                "id": "11222333-9",
                "name": "Daniel Bot",
                "to": "2027-10-29T11:38:23",
                "isActive": true,
                "...": "..."
            },
            "...": "..."
        }
    }
}
```

Si no es válida, `valid` es `false` y el motivo está en `error.message`. Por ejemplo, si el XML se modificó después de firmarlo:

```json
{
    "data": {
        "valid": false,
        "error": {
            "message": "The DigestValue that comes in the XML \"76PnCAaCZb2XiWjKywMj4K3Qvko=\" for the reference \"LibreDTE_88888888-8_T033F000000000001\" does not match the calculated value when validating \"KRgsXYrcUs+tmoE7Tg9UiOgWiSQ=\". The data of the reference could have been manipulated after being signed.",
            "code": 0,
            "errors": []
        },
        "signature": { "...": "..." }
    }
}
```

Revisa siempre `valid`: el código `200` solo indica que la validación se hizo, no que la firma sea válida.

Para no romper la firma, guarda y envía el `document_xml` tal como lo entrega la API.

## ¿Cuándo validar?

| Etapa | Recomendación |
|-------|---------------|
| Desarrollo y pruebas | Valida el esquema de **todos** los documentos. |
| Producción | Valida al menos el esquema. Cuesta pocos créditos y te evita rechazos del SII. |

> [!TIP] El sobre también se valida
>
> En el siguiente paso armarás el sobre. Para el sobre existen las mismas validaciones: `billing/document/dispatcher/validate`, `billing/document/dispatcher/validateSchema` y `billing/document/dispatcher/validateSignature`. Esta última responde una lista, con un resultado por cada firma del sobre: la de cada documento y la del sobre.

> [!INFO] La validación no reemplaza al SII
>
> Estas validaciones revisan el formato y los datos. Hay reglas que solo el SII puede verificar, como que el folio esté autorizado o que el certificado esté autorizado para la empresa. La respuesta final siempre la da el SII en el [paso 5](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-5-consultar-el-estado).


    
---

## Paso 3: Armar el sobre (obligatorio)

Qué es el sobre (EnvioBOLETA para las boletas y EnvioDTE para los demás documentos), cómo crearlo con dispatcher/create y cómo dirigirlo al SII.

# Paso 3: Armar el sobre (obligatorio)

El SII no recibe documentos sueltos: recibe un **sobre** que contiene uno o más documentos. Las facturas, notas y guías van en un sobre `EnvioDTE` y las boletas en un sobre `EnvioBOLETA`. Los dos se crean con la misma operación, `dispatcher/create`, que elige el tipo según el documento (ver [Un sobre por tipo de documento](#un-sobre-por-tipo-de-documento)).

El sobre tiene una **carátula** con:

| Dato de la carátula | Qué es | De dónde sale |
|---------------------|--------|---------------|
| `RutEmisor` | RUT de la empresa emisora | `emisor.rut` |
| `RutEnvia` | RUT de la persona que envía | El certificado digital |
| `RutReceptor` | A quién va dirigido el sobre | `receptor.rut` (ver abajo) |
| `FchResol` y `NroResol` | Resolución de autorización del emisor | `emisor.autorizacion_dte` |
| `SubTotDTE` | Cuántos documentos de cada tipo lleva | Se calcula solo |

El sobre también se **firma** con el certificado digital.

## Crear el sobre para el SII

```
POST https://app.apigateway.cl/api/v2/libredte/billing/document/dispatcher/create
```

```json
{
    "parameters": {
        "bag": {
            "xmlDocument": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8RFRF...",
            "certificate": {
                "certificate": "-----BEGIN CERTIFICATE-----\nMIIG...\n-----END CERTIFICATE-----",
                "privateKey": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----"
            },
            "emisor": {
                "rut": "88888888-8",
                "razon_social": "Mi Empresa SpA",
                "autorizacion_dte": {
                    "fecha_resolucion": "2025-11-20",
                    "numero_resolucion": 0
                }
            },
            "receptor": {
                "rut": "60803000-K"
            }
        }
    }
}
```

| Campo | Qué es |
|-------|--------|
| `xmlDocument` | El `document_xml` del [paso 1](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-1-construir-el-dte), en base64. |
| `certificate` | El certificado con que se firma el sobre. |
| `emisor.autorizacion_dte` | La resolución del emisor: en **certificación**, número `0` y la fecha que muestra el SII en ese ambiente; en **producción**, el número y la fecha de la resolución real. |
| `receptor.rut` | A quién va dirigido el sobre. Para el SII usa `60803000-K`, el RUT del SII. |

## ¿Dónde obtengo la fecha y el número de resolución?

Son datos del emisor que entrega el SII, y cada ambiente tiene los suyos. Puedes obtenerlos de dos formas:

**Con la API**, consultando el estado de autorización del emisor:

```bash
# Producción
curl https://app.apigateway.cl/api/v2/sii/dte/contribuyentes/autorizado/88888888-8 \
  -H "Authorization: Token $API_TOKEN"

# Certificación
curl "https://app.apigateway.cl/api/v2/sii/dte/contribuyentes/autorizado/88888888-8?certificacion=1" \
  -H "Authorization: Token $API_TOKEN"
```

La resolución viene en `data.resolucion`. Esta es la respuesta en certificación:

```json
{
    "data": {
        "rut": "88888888-8",
        "autorizado": true,
        "resolucion": {
            "numero": 0,
            "fecha": "2025-11-20"
        }
    }
}
```

Usa `resolucion.fecha` como `fecha_resolucion` y `resolucion.numero` como `numero_resolucion`. En certificación el número siempre es `0`.

**En el sitio del SII**, buscando al emisor por su RUT en el listado de empresas autorizadas: [certificación](https://maullin.sii.cl/cvc/dte/ee_empresas_dte.html) o [producción](https://palena.sii.cl/cvc/dte/ee_empresas_dte.html).

> [!TIP] Consúltala una vez y guárdala
>
> La resolución no cambia de un envío a otro. Consúltala una vez por emisor y ambiente, y guárdala en la configuración de la empresa. Más detalles en [Resolución de autorización](https://www.apigateway.cl/academy/emision-de-dte/fundamentos/resolucion-de-autorizacion).

## La respuesta

Esta es la respuesta para el sobre del ejemplo. Los valores largos están acortados con `...`, y de `documents` se muestran solo los campos propios del sobre: el resto es igual a la [respuesta de `builder/build`](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-1-construir-el-dte#la-respuesta).

```json
{
    "data": {
        "tag": "EnvioDTE",
        "xml": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0i...",
        "documents": [
            {
                "document_id": "88888888-8_T033F000000001",
                "document_xml": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8RFRF...",
                "document_auth": {
                    "FchResol": "2025-11-20",
                    "NroResol": 0
                },
                "...": "los demás campos de builder/build (ver el paso 1)"
            }
        ],
        "caratula": {
            "@attributes": {
                "version": "1.0"
            },
            "RutEmisor": "88888888-8",
            "RutEnvia": "11222333-9",
            "RutReceptor": "60803000-K",
            "FchResol": "2025-11-20",
            "NroResol": 0,
            "TmstFirmaEnv": "2026-10-30T09:23:51",
            "SubTotDTE": [
                {
                    "TpoDTE": 33,
                    "NroDTE": 1
                }
            ]
        }
    }
}
```

| Campo | Qué es | ¿Guardarlo? |
|-------|--------|-------------|
| `xml` | **El sobre firmado, en base64.** Es lo que enviarás al SII en el [paso 4](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-4-enviar-al-sii). | Sí, siempre |
| `tag` | El tipo de sobre: `EnvioDTE`, o `EnvioBOLETA` si son boletas. | No |
| `caratula` | La carátula del sobre: emisor, quién envía (`RutEnvia`, el RUT del certificado), a quién va dirigido, la resolución, la fecha de firma y cuántos documentos de cada tipo lleva (`SubTotDTE`). | Opcional |
| `documents` | Los documentos que van dentro del sobre, con los mismos campos que entrega [`builder/build`](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-1-construir-el-dte#la-respuesta). `document_auth` trae la resolución que indicaste. | No |

> [!WARNING] Guarda solo lo necesario
>
> Cada documento de `documents` incluye los datos del certificado, con su llave privada (`certificate.pkey`). No guardes la respuesta completa en tu base de datos ni en tus logs: guarda el `xml` del sobre.

## Varios documentos en un sobre

Si emites muchos documentos a la vez, puedes enviarlos en un solo sobre con `dispatcher/createMany`. Recibe una lista de bolsas en el parámetro `bags`, todas del **mismo emisor**:

```json
{
    "parameters": {
        "bags": [
            {
                "xmlDocument": "...DTE 1 en base64...",
                "certificate": { "certificate": "...", "privateKey": "..." },
                "emisor": { "rut": "88888888-8", "razon_social": "Mi Empresa SpA", "autorizacion_dte": { "fecha_resolucion": "2025-11-20", "numero_resolucion": 0 } },
                "receptor": { "rut": "60803000-K" }
            },
            {
                "xmlDocument": "...DTE 2 en base64..."
            }
        ]
    }
}
```

El certificado, el emisor y el receptor del sobre se toman de la primera bolsa.

> [!TIP] ¿Uno por sobre o varios?
>
> Para empezar, usa **un documento por sobre**: es más simple saber qué documento tiene cada Track ID, y si el SII rechaza uno no afecta a los demás. Agrupa documentos en un sobre solo cuando el volumen lo justifique.

## Un sobre por tipo de documento

La llamada es la misma para todos los documentos: envía en `xmlDocument` el `document_xml` del documento, sea una factura o una boleta. La API elige el tipo de sobre y lo informa en `tag`:

| Documento en `xmlDocument` | `tag` de la respuesta | `caratula.SubTotDTE` | Se envía con (paso 4) |
|----------------------------|-----------------------|----------------------|-----------------------|
| Factura, nota o guía | `EnvioDTE` | `[{ "TpoDTE": 33, "NroDTE": 1 }]` | `sii_dte/sendXmlDocument` |
| Boleta | `EnvioBOLETA` | `[{ "TpoDTE": 39, "NroDTE": 1 }]` | `sii_boleta/sendXmlDocument` |

El resto de la respuesta tiene los mismos campos en los dos casos.

Un sobre lleva solo boletas o solo los demás DTE, nunca ambos. Si intentas juntarlos (por ejemplo, con `createMany`, ver [Varios documentos en un sobre](#varios-documentos-en-un-sobre)), la API responde:

```
El tipo de documento Factura electrónica no se puede agregar a un sobre de tipo ENVIO_BOLETA.
```


    
---

## Paso 4: Enviar al SII (obligatorio)

Cómo enviar el sobre al SII: las facturas, notas y guías con sii_dte/sendXmlDocument y las boletas con sii_boleta/sendXmlDocument, cómo elegir el ambiente y qué hacer con el Track ID.

# Paso 4: Enviar al SII (obligatorio)

Con el sobre firmado, lo envías al SII. El SII lo recibe, le asigna un **Track ID** y lo procesa en segundo plano. El resultado (aceptado o rechazado) se consulta después, en el [paso 5](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-5-consultar-el-estado).

## Qué operación usar

El SII recibe las boletas por un servicio distinto al de los demás documentos, así que hay una operación para cada tipo de sobre:

| Sobre del paso 3 (`tag`) | Documentos | Operación |
|--------------------------|------------|-----------|
| `EnvioDTE` | Facturas, notas de crédito y débito, guías de despacho y demás DTE | `billing/integration/sii_dte/sendXmlDocument` |
| `EnvioBOLETA` | Boletas (`39` y `41`) | `billing/integration/sii_boleta/sendXmlDocument` |

Las dos reciben los mismos parámetros y entregan un Track ID.

## 4.1. Facturas, notas y guías

### La solicitud

```
POST https://app.apigateway.cl/api/v2/libredte/billing/integration/sii_dte/sendXmlDocument
```

```json
{
    "parameters": {
        "request": {
            "certificate": {
                "certificate": "-----BEGIN CERTIFICATE-----\nMIIG...\n-----END CERTIFICATE-----",
                "privateKey": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----"
            },
            "options": {
                "environment": 1
            }
        },
        "doc": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8RW52aW9EVEU...",
        "company": "88888888-8"
    }
}
```

| Parámetro | Qué es |
|-----------|--------|
| `request.certificate` | El certificado con que la API se autentica en el SII. |
| `request.options.environment` | El ambiente del SII: `1` certificación, `0` producción. |
| `doc` | El sobre `EnvioDTE` del [paso 3](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-3-armar-el-sobre) (su campo `xml`), en base64. |
| `company` | El RUT de la empresa emisora. |
| `retries` | (Opcional) Cuántas veces reintentar si el SII no responde. Máximo `10`. |

### La respuesta

```json
{
    "data": {
        "track_id": 4753411374
    }
}
```

El **Track ID** es el comprobante de que el SII recibió el sobre. **Guárdalo inmediatamente** junto al documento: sin él no puedes consultar el resultado.

## 4.2. Boletas

### La solicitud

```
POST https://app.apigateway.cl/api/v2/libredte/billing/integration/sii_boleta/sendXmlDocument
```

Los parámetros son **los mismos de 4.1** (`request`, `doc`, `company` y `retries`). La diferencia está en `doc`: va el sobre `EnvioBOLETA` del [paso 3](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-3-armar-el-sobre#un-sobre-por-tipo-de-documento).

### La respuesta

```json
{
    "data": {
        "track_id": 33790541,
        "status": "REC",
        "received_at": "2026-11-04T12:18:29-03:00",
        "rut_sender": "11222333-9",
        "rut_company": "88888888-8",
        "retry_after": 5,
        "location": "https://apicert.sii.cl/recursos/v1/boleta.electronica.envio/88888888-8-33790541",
        "rate_limit": {
            "limit": 10,
            "remaining": 10,
            "reset": 1
        },
        "file": "libredte_boleta.xml"
    }
}
```

| Campo | Qué es |
|-------|--------|
| `track_id` | El número de seguimiento del envío. **Guárdalo inmediatamente**: con él consultas el estado. |
| `status` | El estado del envío al recibirlo: `REC`, recibido. |
| `received_at` | Fecha y hora en que el SII recibió el sobre. |
| `rut_sender` | El RUT de quien envía: la persona del certificado. |
| `rut_company` | El RUT de la empresa emisora. |
| `retry_after` | Los segundos que el SII pide esperar **antes de consultar el estado** del envío. Es parte normal de la respuesta, no un error. Puede venir en `null`. |
| `rate_limit` | El límite de solicitudes que informa el servicio de boletas del SII: cuántas permite (`limit`), cuántas quedan (`remaining`) y en cuántos segundos se reinicia la cuenta (`reset`). Puede venir en `null`. |
| `location` | La ruta del SII para consultar el resultado del envío. No necesitas guardarla: el estado se consulta con el Track ID. |
| `file` | El nombre con que la API subió el archivo al SII. |

## Para los dos envíos

> [!WARNING] Indica siempre el ambiente
>
> Si no envías `options.environment`, el documento se envía a **producción**. Durante el desarrollo usa siempre `"environment": 1`, y asegúrate de que el CAF y la resolución sean del mismo ambiente al que envías.

> [!INFO] Recibido no es aceptado
>
> Que el SII entregue un Track ID solo significa que **recibió** el sobre. Todavía puede rechazarlo por un error en los datos, en la firma o en la carátula. Para saber el resultado tienes que consultar el estado.

## Errores frecuentes en este paso

| Situación | Causa probable | Qué hacer |
|-----------|----------------|-----------|
| `No fue posible obtener el token para autenticar en el SII al usuario ...` | El SII no aceptó el certificado: no es válido, está vencido, es autofirmado, o la persona no está registrada en el SII para la empresa. | Revisa el certificado y que esa persona sea usuario autorizado de la empresa en el SII. |
| Error al enviar el XML | El SII no respondió o rechazó el archivo al recibirlo. | Revisa el mensaje de `detail` y reintenta más tarde si es un problema del SII. |
| RUT inválido | `company` mal escrito. | Usa el RUT sin puntos y con guion. |
| `El XML es un EnvioBOLETA y no se puede enviar con el worker de DTE, las boletas se envían con el worker de boletas.` | Enviaste un sobre de boletas con `sii_dte`. | Envía los sobres `EnvioBOLETA` con `sii_boleta/sendXmlDocument`. Revisa el `tag` del sobre antes de elegir la operación. |
| Boletas: `rate_limit.remaining` en `0` | Usaste todas las solicitudes que permite el servicio de boletas del SII. | Espera los segundos de `rate_limit.reset` antes de volver a llamar. |

## Si el SII no está disponible

El SII a veces está lento o fuera de servicio. Como el documento ya está construido y firmado, no lo pierdes:

1. Guarda el documento con estado "error de envío".
2. Reintenta el envío más tarde (por ejemplo, cada 15 o 30 minutos) con un proceso automático.
3. Si los reintentos fallan por mucho tiempo, avisa a un responsable.

> [!WARNING] Nunca construyas de nuevo un documento solo porque falló el envío
>
> Si construyes de nuevo, obtienes otro XML con otra firma para el mismo folio. Reintenta el envío del **mismo sobre** que ya tenías.


    
---

## Paso 5: Consultar el estado (obligatorio)

Cómo saber si el SII aceptó, aceptó con reparos o rechazó el envío de facturas, notas, guías o boletas, cómo interpretar los estados y cómo obtener el detalle de un rechazo.

# Paso 5: Consultar el estado (obligatorio)

El SII procesa los envíos en segundo plano. Con el **Track ID** del paso anterior consultas en qué va el procesamiento y, al final, si los documentos fueron aceptados o rechazados.

## Qué operación usar

Se consulta con el mismo servicio con que enviaste:

| Enviaste con | Consulta con |
|--------------|--------------|
| `sii_dte/sendXmlDocument` (sobre `EnvioDTE`) | `billing/integration/sii_dte/checkXmlDocumentSentStatus` |
| `sii_boleta/sendXmlDocument` (sobre `EnvioBOLETA`) | `billing/integration/sii_boleta/checkXmlDocumentSentStatus` |

Las dos reciben los mismos parámetros. Usa el mismo ambiente (`environment`) que usaste al enviar.

## 5.1. Facturas, notas y guías

### La solicitud

```
POST https://app.apigateway.cl/api/v2/libredte/billing/integration/sii_dte/checkXmlDocumentSentStatus
```

```json
{
    "parameters": {
        "request": {
            "certificate": {
                "certificate": "-----BEGIN CERTIFICATE-----\nMIIG...\n-----END CERTIFICATE-----",
                "privateKey": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----"
            },
            "options": {
                "environment": 1
            }
        },
        "trackId": 4753411374,
        "company": "88888888-8"
    }
}
```

### La respuesta

```json
{
    "data": {
        "query_number": 532120,
        "query_datetime": "2026-10-30T09:31:02",
        "track_id": 4753411374,
        "company": "88888888-8",
        "status": "EPR",
        "error": false,
        "description": "Envío Procesado",
        "resume": {
            "reported": 1,
            "accepted": 1,
            "rejected": 0,
            "repairs": 0
        },
        "documents": {
            "33": {
                "type": 33,
                "reported": 1,
                "accepted": 1,
                "rejected": 0,
                "repairs": 0
            }
        }
    }
}
```

| Campo | Qué es |
|-------|--------|
| `status` | Código del estado del envío (ver tabla). |
| `error` | `true` si el envío fue rechazado o hubo un error en la consulta. |
| `description` | Glosa del estado que entrega el SII. |
| `resume` | Cuántos documentos se informaron, aceptaron, rechazaron o tienen reparos. |
| `documents` | El mismo resumen, por tipo de documento. |
| `query_number`, `query_datetime` | El número y la fecha de la consulta en el SII. |

### Los estados del envío

| `status` | Significado | ¿Es final? | Qué hacer |
|----------|-------------|------------|-----------|
| `SOK` | Esquema validado | No | Consulta de nuevo más tarde |
| `CRT` | Carátula OK | No | Consulta de nuevo más tarde |
| `FOK` | Firma del envío validada | No | Consulta de nuevo más tarde |
| `PDR` | Envío en proceso | No | Consulta de nuevo más tarde |
| `EPR` | **Envío procesado** | Sí | Revisa `resume` (ver abajo) |
| `RSC` | Rechazado por error en el esquema | Sí | Corrige el XML y emite de nuevo, con el mismo folio |
| `RFR` | Rechazado por error en la firma | Sí | Revisa el certificado y emite de nuevo, con el mismo folio |
| `RCT` | Rechazado por error en la carátula | Sí | Revisa el emisor, la resolución y el ambiente del sobre |

Cuando el estado es `EPR`, el resultado de cada documento está en `resume`:

| Resultado | Cómo se ve | Significado |
|-----------|------------|-------------|
| **Aceptado** | `accepted` = `reported` | El documento es válido. |
| **Aceptado con reparos** | `repairs` > 0 | El documento es válido, pero tiene observaciones menores. Revísalas para corregir los siguientes documentos. |
| **Rechazado** | `rejected` > 0 | El documento **no es válido**. Hay que corregirlo y emitirlo de nuevo, con el mismo folio. |

> [!INFO] Los códigos negativos
>
> Si `status` es un número negativo (por ejemplo `-11`) o un código como `001`, es un error de la **consulta** (no del documento): el Track ID no existe, el usuario no está autorizado o la sesión del SII expiró. Revisa `description` y que el RUT de `company` sea el mismo con que enviaste.

### ¿Por qué fue rechazado?

El estado indica **que** un documento fue rechazado, pero no siempre **por qué**. Para obtener el detalle, pide al SII que te envíe el resultado por correo:

```
POST https://app.apigateway.cl/api/v2/libredte/billing/integration/sii_dte/requestXmlDocumentSentStatusByEmail
```

```json
{
    "parameters": {
        "request": {
            "certificate": { "certificate": "-----BEGIN CERTIFICATE-----\nMIIG...\n-----END CERTIFICATE-----", "privateKey": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----" },
            "options": { "environment": 1 }
        },
        "trackId": 4753411374,
        "company": "88888888-8"
    }
}
```

La respuesta confirma que el SII recibió la solicitud:

```json
{
    "data": {
        "company": "88888888-8",
        "track_id": 4753411374,
        "status": "0",
        "description": "Requerimiento recibido OK."
    }
}
```

El SII envía el detalle de los rechazos al **correo configurado en el SII** para la empresa (no se puede elegir otro desde la API).

## 5.2. Boletas

### La solicitud

```
POST https://app.apigateway.cl/api/v2/libredte/billing/integration/sii_boleta/checkXmlDocumentSentStatus
```

Los parámetros son **los mismos de 5.1** (`request`, `trackId` y `company`), con el Track ID que entregó `sii_boleta/sendXmlDocument`.

### La respuesta

Mientras el SII procesa el envío, el estado no es final y todavía no hay resultados:

```json
{
    "data": {
        "track_id": 33790541,
        "company": "88888888-8",
        "status": "SOK",
        "error": false,
        "description": "Schema validado",
        "resume": {
            "reported": 0,
            "accepted": 0,
            "rejected": 0,
            "repairs": 0
        },
        "documents": [],
        "received_at": "2026-11-04T12:18:29-03:00",
        "sender": "11222333-9",
        "retry_after": null,
        "location": null,
        "rate_limit": null,
        "details": []
    }
}
```

Cuando el estado es final, `resume` y `documents` traen los resultados, igual que en 5.1. Si el SII rechazó algo, `error` es `true` y `details` explica el motivo. En este ejemplo el SII rechazó el envío completo por un error de schema: el giro del emisor superaba el largo máximo.

```json
{
    "data": {
        "track_id": 33790541,
        "company": "88888888-8",
        "status": "RSC",
        "error": true,
        "description": "Rechazado por schema",
        "resume": {
            "reported": 0,
            "accepted": 0,
            "rejected": 0,
            "repairs": 0
        },
        "documents": [],
        "received_at": "2026-11-04T12:18:29-03:00",
        "sender": "11222333-9",
        "retry_after": null,
        "location": null,
        "rate_limit": null,
        "details": [
            {
                "type": null,
                "folio": null,
                "status": "RCH",
                "description": "DTE Rechazado",
                "errors": [
                    {
                        "section": "ENV",
                        "line": 0,
                        "level": 3,
                        "code": 0,
                        "description": "Error en Schema",
                        "detail": "[0] LSX-00222: \"VENTA AL POR MENOR DE COMPUTADORES, EQUIPO PERIFERICO, PROGR"
                    }
                ]
            }
        ]
    }
}
```

| Campo | Qué es |
|-------|--------|
| `status` | Código del estado del envío (ver tabla). |
| `error` | `true` si el envío o alguna boleta fue rechazada. |
| `description` | Explicación del estado. |
| `resume` | Cuántas boletas se informaron, aceptaron, rechazaron o tienen reparos. |
| `documents` | El mismo resumen, por tipo de documento (`39` o `41`). Mientras no hay resultados, viene vacío (`[]`). |
| `details` | **Una entrada por cada problema**: una boleta rechazada o con reparos, o el envío completo si el rechazo es de todo el sobre. Si no hay problemas, viene vacío. |
| `received_at`, `sender` | Cuándo recibió el SII el sobre y quién lo envió. |
| `retry_after`, `rate_limit` | La espera que pide el SII y el límite de solicitudes del servicio de boletas (ver [paso 4](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-4-enviar-al-sii#42-boletas)). Pueden venir en `null`. |

### Los estados del envío de boletas

| `status` | Significado | ¿Es final? | Qué hacer |
|----------|-------------|------------|-----------|
| `REC` | Envío recibido | No | Consulta de nuevo más tarde |
| `SOK` | Schema validado | No | Consulta de nuevo más tarde |
| `CRT` | Carátula OK | No | Consulta de nuevo más tarde |
| `FOK` | Firma del envío validada | No | Consulta de nuevo más tarde |
| `PRD` | Envío en proceso | No | Consulta de nuevo más tarde |
| `EPR` | **Envío procesado** | Sí | Revisa `resume` y `details` |
| `RPR` | Aceptado con reparos | Sí | Revisa `details` para corregir las siguientes boletas |
| `RCH` | Rechazado por errores en la información | Sí | Revisa `details`, corrige y emite de nuevo, con el mismo folio |
| `RCO` | Rechazado por consistencia | Sí | Revisa `details`, corrige y emite de nuevo, con el mismo folio |
| `RSC` | Rechazado por schema | Sí | Corrige el XML y emite de nuevo, con el mismo folio |
| `RFR` | Rechazado por error en la firma | Sí | Revisa el certificado y emite de nuevo, con el mismo folio |
| `RCT` | Rechazado por error en la carátula | Sí | Revisa el emisor, la resolución y el ambiente del sobre |
| `RPT` | Envío repetido rechazado | Sí | Ese sobre ya se había enviado: consulta el estado con el Track ID del primer envío |
| `VOF` | No se encontró el archivo XML | Sí | Envía de nuevo el mismo sobre |

En los estados de rechazo, `error` es `true`.

### ¿Por qué fue rechazada una boleta?

A diferencia de las facturas, notas y guías, el detalle viene **en la misma respuesta**, en `details`. Cada entrada tiene:

| Campo | Qué es |
|-------|--------|
| `type` y `folio` | Qué boleta es. Vienen en `null` cuando el rechazo es de todo el envío, como en el ejemplo. |
| `status` | `DOK` aceptada, `RLV` aceptada con reparos leves, `RPR` aceptada con reparos, `RCH` rechazada. |
| `description` | Explicación del estado. |
| `errors` | Los problemas encontrados. `section` es la parte del documento (`ENV` envío, `CRT` carátula, `HED` encabezado, `DET` detalle, `REF` referencias, `TED` timbre, `CAF` folios, `DTE` documento); `level` es la gravedad (`1` reparo leve, `2` reparo, `3` rechazo); `description` y `detail` explican el problema. |

## Qué hacer con el folio según el resultado

La regla es la misma para facturas, notas, guías y boletas, y vale tanto si el SII rechaza el envío completo como si rechaza solo un documento dentro de un envío procesado:

| Resultado | ¿Es válido? | El folio | Qué hacer |
|-----------|-------------|----------|-----------|
| **Aceptado** | Sí | Queda usado. | Guarda el estado. |
| **Aceptado con reparos** | Sí | Queda usado: **no se puede volver a usar**. | Revisa los reparos para no repetirlos en los documentos siguientes. |
| **Rechazado** | No: el SII lo considera no emitido. | Queda libre: **se puede volver a usar**. | Corrige los datos y emite el documento de nuevo **con el mismo folio**: constrúyelo otra vez (paso 1), arma un sobre nuevo (paso 3) y envíalo (paso 4). |

> [!WARNING] Un rechazo no es un envío fallido
>
> Si el envío **falló** (el SII no respondió y no tienes Track ID), el documento no se construye de nuevo: reintenta el envío del mismo sobre. Solo cuando el SII **rechazó** el documento lo construyes otra vez, corregido y con el mismo folio.

## Cada cuánto consultar

El SII suele procesar un envío en pocos minutos, pero puede demorar más en horas de alta carga. Una estrategia razonable:

1. Espera unos 30 segundos después del envío antes de la primera consulta.
2. Si el estado no es final, vuelve a consultar con esperas cada vez más largas (1, 2, 5, 10 minutos...).
3. Si después de varias horas sigue sin estado final, márcalo para revisión.

Un estado es final cuando ya no va a cambiar. Cualquier otro código significa que el SII sigue procesando, o que la consulta misma falló (por ejemplo, un código negativo): en los dos casos se vuelve a consultar más tarde. Esta función sirve para facturas y boletas; solo cambia el worker. Usa la función `libredte()` de [Tu primera llamada](https://www.apigateway.cl/academy/emision-de-dte/preparacion/tu-primera-llamada#en-python):

```python
import time

ESTADOS_FINALES = {'EPR', 'LOK', 'RPR', 'RLV', 'RCH', 'RCO', 'RFR', 'RSC', 'RCT', 'RPT', 'VOF'}


def esperar_estado(worker: str, request_sii: dict, track_id: int, company: str,
                   espera_inicial: int = 30) -> dict | None:
    """Consulta el estado hasta que sea final.

    worker: 'sii_dte' (facturas, notas y guías) o 'sii_boleta' (boletas).
    espera_inicial: en boletas, usa max(30, retry_after or 0) de la respuesta del envío.
    Entrega el estado final, o None si se acabaron las esperas sin estado final.
    """
    for espera in [espera_inicial, 60, 120, 300, 600, 1800, 3600, 7200]:   # segundos
        time.sleep(espera)
        try:
            estado = libredte(f'billing/integration/{worker}/checkXmlDocumentSentStatus', {
                'request': request_sii,
                'trackId': track_id,
                'company': company,
            })
        except RuntimeError:
            continue   # La consulta falló (por ejemplo, el SII no respondió): se reintenta.
        if estado['status'] in ESTADOS_FINALES:
            return estado
    return None   # Sin estado final: márcalo para revisión.
```

Por ejemplo, para una factura: `esperar_estado('sii_dte', {'certificate': CERTIFICADO, 'options': {'environment': 1}}, track_id, '88888888-8')`.

> [!TIP] Consulta desde un proceso en segundo plano
>
> No hagas esperar al usuario mientras el SII procesa. Emite, envía, guarda el Track ID y deja que un proceso programado (cron, cola de tareas) consulte los estados pendientes.

## Verificar un documento puntual

Cuando un documento ya fue aceptado, puedes verificar que exista en el SII y que sus datos coincidan.

### Facturas, notas y guías

Usa el recurso de **Documentos Emitidos**, con el tipo, el folio, la fecha, el monto y el receptor:

```bash
curl -X POST "https://app.apigateway.cl/api/v2/sii/dte/emitidos/verificar?certificacion=1" \
  -H "Authorization: Token $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "auth": {
        "cert": {
            "cert-data": "-----BEGIN CERTIFICATE-----\nMIIG...\n-----END CERTIFICATE-----",
            "pkey-data": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----"
        }
    },
    "dte": {
        "emisor": "88888888-8",
        "dte": 33,
        "folio": 1,
        "fecha": "2026-10-29",
        "total": 119000,
        "receptor": "77777777-7"
    }
}'
```

La respuesta:

```json
{
    "data": {
        "status": "DOK",
        "detalle": "Documento recibido por el SII. Datos coinciden con los registrados.",
        "track_id": 4753411374,
        "razon_social": "MI EMPRESA SPA"
    }
}
```

| `status` | Significado |
|----------|-------------|
| `DOK` | Documento recibido por el SII. Los datos coinciden. |
| `DNK` | Documento recibido por el SII, pero los datos **no** coinciden. |
| `FAU` | El SII no ha recibido un documento con ese folio. |
| `FNA` | El folio no está autorizado por el SII. |

`track_id` es el del envío en que llegó el documento (`0` si el SII no lo informa) y `razon_social` es la del emisor según el SII (`null` si no viene).

### Boletas

Usa `sii_boleta/validateDocument`. El SII exige todos los datos: el tipo, el folio, la fecha, el total y el receptor.

```
POST https://app.apigateway.cl/api/v2/libredte/billing/integration/sii_boleta/validateDocument
```

```json
{
    "parameters": {
        "request": {
            "certificate": {
                "certificate": "-----BEGIN CERTIFICATE-----\nMIIG...\n-----END CERTIFICATE-----",
                "privateKey": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----"
            },
            "options": {
                "environment": 1
            }
        },
        "company": "88888888-8",
        "document": 39,
        "number": 1,
        "date": "2026-11-04",
        "total": 23800,
        "recipient": "66666666-6"
    }
}
```

| Parámetro | Qué es |
|-----------|--------|
| `company` | El RUT del emisor. |
| `document` | El tipo de boleta: `39` o `41`. |
| `number` | El folio. |
| `date` | La fecha de emisión (`AAAA-MM-DD`). |
| `total` | El total de la boleta. |
| `recipient` | El RUT del receptor (`66666666-6` si no se identificó). |

La respuesta:

```json
{
    "data": {
        "status": "DOK",
        "description": "Documento Recibido por el SII. Datos Coinciden con los Registrados",
        "rate_limit": null
    }
}
```

Los códigos que puede traer `status`:

| `status` | Significado |
|----------|-------------|
| `DOK` | Boleta recibida por el SII. Los datos coinciden. |
| `DNK` | Boleta recibida por el SII, pero los datos **no** coinciden. |
| `FAU` | El SII no ha recibido una boleta con ese folio. |
| `FNA` | El folio no está autorizado por el SII. |
| `FAN` | La boleta fue anulada. |
| `EMP` | La empresa no está autorizada a emitir documentos electrónicos. |
| `ANC`, `MMC`, `TMC` | Una nota de crédito anula la boleta, modifica sus montos o modifica su texto. |
| `AND`, `MMD`, `TMD` | Una nota de débito anula la boleta, modifica sus montos o modifica su texto. |

> [!NOTE] Otra forma de consultar el estado de facturas, notas y guías
>
> El recurso `POST /api/v2/sii/dte/emitidos/estado_envio/{emisor}/{trackId}` también entrega el estado de un envío `EnvioDTE`, con el certificado en `auth.cert`. Revisa la [documentación de la API](https://www.apigateway.cl/docs/api) en **API DTE - Documentos Emitidos**.


    
---

## Paso 6: Generar el PDF (opcional)

Cómo generar la representación impresa del DTE con renderer/render: copias tributaria y cedible, formatos y diseños disponibles.

# Paso 6: Generar el PDF (opcional)

El cliente no lee XML: necesita un documento para ver, imprimir o archivar. La operación **`renderer/render`** genera la **representación impresa** del documento, con el timbre electrónico dibujado como código de barras (el que el SII llama PDF417). Es la misma operación para todos los documentos, incluidas las boletas.

> [!NOTE] ¿Por qué es opcional?
>
> El documento con validez legal es el XML, no el PDF, y la API no exige generarlo. Pero el cliente necesita un documento que pueda ver o imprimir, así que en la práctica casi todas las integraciones lo generan.

## La solicitud

```
POST https://app.apigateway.cl/api/v2/libredte/billing/document/renderer/render
```

```json
{
    "parameters": {
        "bag": {
            "xmlDocument": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iSVNPLTg4NTktMSI/Pgo8RFRF...",
            "emisor": {
                "rut": "88888888-8",
                "razon_social": "Mi Empresa SpA",
                "autorizacion_dte": {
                    "fecha_resolucion": "2025-11-20",
                    "numero_resolucion": 0
                }
            },
            "options": {
                "renderer": {
                    "format": "pdf"
                }
            }
        }
    }
}
```

| Campo | Qué es |
|-------|--------|
| `xmlDocument` | El `document_xml` del [paso 1](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-1-construir-el-dte). El PDF se genera desde el XML, así que siempre muestra exactamente lo que se envió al SII. |
| `emisor.autorizacion_dte` | La [resolución del emisor](https://www.apigateway.cl/academy/emision-de-dte/fundamentos/resolucion-de-autorizacion), la misma del sobre. Se imprime al pie del timbre como "Resolución 0 del 2025". |

> [!WARNING] No olvides la resolución
>
> El XML del DTE no incluye la resolución, así que la API no puede deducirla. Si no envías `emisor.autorizacion_dte`, el PDF se genera igual, pero **sin** la línea de la resolución, que debe aparecer en la representación impresa.

## La respuesta

```json
{
    "data": {
        "renderings": [
            {
                "label": "tributaria",
                "mimeType": "application/pdf",
                "filename": "LibreDTE_88888888-8_T033F000000000001_tributaria.pdf",
                "copies": 1,
                "copyNumber": 1,
                "content": "JVBERi0xLjQKJeLjz9MKMyAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQg..."
            }
        ]
    }
}
```

`content` es el archivo en base64. Para guardarlo:

```python
import base64

resultado = libredte('billing/document/renderer/render', {
    'bag': {
        'xmlDocument': document_xml,  # El document_xml del paso 1.
        'emisor': EMISOR,  # rut, razon_social y autorizacion_dte, como en el sobre.
        'options': {'renderer': {'format': 'pdf'}},
    },
})
for archivo in resultado['renderings']:
    with open(archivo['filename'], 'wb') as f:
        f.write(base64.b64decode(archivo['content']))
```

## Copia tributaria y copia cedible

| Copia | Para qué |
|-------|----------|
| **Tributaria** | La copia normal del documento. Es la que se genera por defecto. |
| **Cedible** | Una copia con la leyenda "CEDIBLE" y el acuse de recibo, que el cliente firma al recibir la mercadería. Se usa para **ceder** la factura (factoring). |

Las **boletas** solo tienen copia tributaria: no se ceden.

Pide las copias que necesites, y cuántas de cada una, con `renderings`:

```json
"options": {
    "renderer": {
        "format": "pdf",
        "renderings": {
            "tributaria": 1,
            "cedible": 1
        }
    }
}
```

La respuesta trae un elemento en `renderings` por cada copia, con su propio `label` y `filename`.

> [!INFO] La copia cedible no aplica a todos los documentos
>
> Si pides una copia cedible de un documento que no la admite (por ejemplo, una nota de crédito o una boleta), esa copia simplemente no aparece en la respuesta. No es un error.

## Diseños y formatos

| Opción | Valores | Por defecto |
|--------|---------|-------------|
| `format` | `pdf` o `html` | `pdf` |
| `strategy` | `template.estandar`, `template.general`, `template.servicios_basicos` | `template.estandar` |

```json
"options": {
    "renderer": {
        "strategy": "template.general",
        "format": "pdf"
    }
}
```

- **`template.estandar`**: el diseño de LibreDTE, para uso general.
- **`template.general`**: otro diseño para documentos de empresa.
- **`template.servicios_basicos`**: pensado para empresas de servicios básicos.
- **`html`**: entrega el documento en HTML, útil para mostrarlo dentro de tu sistema.

> [!TIP] Muestra al cliente los datos que quieras que vea
>
> El PDF muestra lo que está en el XML. Si quieres que aparezcan el teléfono y el correo del emisor, el correo del cliente o un código de producto, inclúyelos en los datos del [paso 1](https://www.apigateway.cl/academy/emision-de-dte/emision/paso-1-construir-el-dte).

> [!NOTE] Impresoras térmicas
>
> Para puntos de venta con impresora térmica existe además una estrategia que genera comandos ESC/POS. Si la necesitas, revisa la ficha de la operación en la [documentación de la API](https://www.apigateway.cl/docs/api) o [abre un ticket](https://www.apigateway.cl/help).

## Entregar el documento al receptor

Cuando el SII acepta el documento, entrégalo al receptor. **Esto lo hace tu sistema**:

| Receptor | Qué le entregas |
|----------|-----------------|
| Una persona, o una empresa que no emite documentos electrónicos | El PDF. |
| Una empresa que emite documentos electrónicos | El PDF y **el XML** del documento, en un sobre dirigido a ella, enviado a su **correo de intercambio** (el que la empresa registró en el SII). |

Enviarle el XML a una empresa receptora es una obligación del emisor: con ese XML la empresa registra la compra y puede aceptar o reclamar el documento. Las boletas se entregan siempre como PDF (o impresas), porque el receptor es un consumidor final.

## ¿Se puede generar el PDF antes de enviar al SII?

Sí. El PDF solo necesita el XML, así que puedes generarlo apenas construyes el documento, por ejemplo para una vista previa. Para entregarlo al cliente, lo recomendable es esperar a que el SII lo acepte: si el SII lo rechaza, ese documento no tiene validez y el cliente tendría un documento que no sirve.


    

---
Última actualización el 05/11/2026