Emitir boleta y factura electrónica por API en Chile

Integrar la facturación electrónica del SII directamente, a mano, no es un sprint: es un proyecto que se mide en meses. Antes de emitir tu primer documento válido tienes que conseguir un certificado digital, solicitar y administrar folios CAF, firmar el XML con XMLDSig, generar el TED, codificarlo como PDF417, y pasar el set de pruebas en el ambiente de certificación del SII (Palena) antes de tocar producción. Y eso es solo para empezar a emitir; después vienen los rechazos.

Si lo que quieres es emitir boletas y facturas electrónicas por API y volver a tu producto, hay un camino más corto.

Qué resuelve una API de facturación electrónica

El SII define un formato de DTE (Documento Tributario Electrónico) y un protocolo de envío y validación. Una API de facturación se pone delante de toda esa maquinaria y te expone una sola superficie: HTTP, JSON, una API key. Tú describes la venta; la API se encarga del resto del flujo del SII.

Lo que tendrías que construir y mantener tú mismo —y que una API absorbe— incluye:

• Certificado digital. Comprar y custodiar el .p12/.pfx de una AC acreditada (e-certchile, e-Sign, Acepta) y usarlo para firmar cada documento.
• Folios CAF. Solicitar al SII los rangos de folios por tipo de DTE, controlar el consumo y reponer antes de quedarte sin folios.
• Firma XMLDSig. Firmar el XML del documento con la estructura y los algoritmos que el SII exige.
• TED. Generar el Timbre Electrónico y representarlo como código de barras PDF417 en el documento impreso.
• Certificación. Pasar el set de pruebas en Palena para cada tipo de documento antes de habilitar producción.
• Rechazos. Interpretar las respuestas del SII y reaccionar cuando un DTE es rechazado.

Cómo se ve emitir por API

La promesa se entiende mejor con código. Para emitir una boleta o una factura, haces un POST a /v1/dte/boletas con el receptor y los ítems. La API te responde con el folio y el estado.

Base URL: https://api.emitir.cl. Autenticación por header Authorization: Bearer sk_live_•••.

curl https://api.emitir.cl/v1/dte/boletas \
  -H "Authorization: Bearer sk_live_•••" \
  -d '{
    "receptor": { "rut": "76.123.456-7" },
    "items": [{ "glosa": "Plan Pro", "monto": 29990 }]
  }'
# { "folio": 48213, "estado": "aceptado" }

Con el SDK de Node:

const dte = await emitir.boletas.create({
  receptor: { rut: "76.123.456-7" },
  items: [{ glosa: "Plan Pro", monto: 29990 }],
});
console.log(dte.folio, dte.estado); // 48213 "aceptado"

Con el SDK de Python:

dte = emitir.boletas.create(
    receptor={"rut": "76.123.456-7"},
    items=[{"glosa": "Plan Pro", "monto": 29990}],
)
print(dte.folio, dte.estado)  # 48213 "aceptado"

No hay certificado en el código. No hay XML firmado a mano. No hay PDF417. Esa diferencia entre lo que escribes y lo que ocurre es exactamente lo que la API se lleva puesto.

Boletas, facturas y notas

El mismo endpoint POST /v1/dte/boletas emite tanto boletas (DTE tipo 39) como facturas (tipo 33), según el documento que indiques. Conviene tener presente el catálogo de tipos del SII: 33 factura, 34 factura exenta, 39 boleta, 41 boleta exenta, 52 guía de despacho, 56 nota de débito, 61 nota de crédito. El IVA en Chile es 19%; la factura da derecho a crédito fiscal del IVA al receptor, la boleta no. Si quieres entender cuándo emitir cada uno, revisa qué es un DTE y los tipos del SII.

Para anular o corregir un documento ya emitido, usas POST /v1/dte/notas-credito, que genera una nota de crédito (tipo 61) referenciando el DTE original. No se edita el documento: se emite uno nuevo que lo corrige, como exige el SII.

El flujo de estados y los webhooks

Un DTE no nace "aceptado" de forma instantánea: el SII lo procesa. Tienes dos formas de seguir ese ciclo de vida.

Consultar el estado en cualquier momento, junto con el PDF y el XML del documento:

curl https://api.emitir.cl/v1/dte/48213 \
  -H "Authorization: Bearer sk_live_•••"

O, mejor, suscribirte a los cambios de estado con un webhook y dejar que la API te avise:

curl https://api.emitir.cl/v1/webhooks \
  -H "Authorization: Bearer sk_live_•••" \
  -d '{ "url": "https://tu-app.cl/webhooks/emitir" }'

Cuando el SII cambia el estado de un documento, tu endpoint recibe la notificación. Así no consultas en bucle ni dejas al usuario esperando: reaccionas al evento cuando llega.

Saber leer los estados —y por qué un documento puede ser rechazado— sigue siendo útil. Si te topas con rechazos, por qué el SII rechaza un DTE y la gestión de folios CAF del SII explican las causas más frecuentes.

Cuándo conviene una API y cuándo no

Una API de facturación tiene sentido cuando:

• Tu producto emite documentos como parte de su flujo (un checkout, una suscripción, un punto de venta) y no quieres que tu equipo se vuelva experto en la normativa del SII.
• Quieres tiempo de integración en días, no en meses, midiendo el avance en líneas de código y no en trámites.
• Prefieres que el certificado, los folios, la firma y la certificación sean responsabilidad de la plataforma.

Si solo necesitas emitir un puñado de documentos manuales al mes, el portal del SII o un facturador con interfaz gráfica te alcanzan. La API es para cuando la emisión es parte de tu software.

Empieza por la lista de espera

Emitir está en desarrollo y el acceso es por lista de espera. Si estás evaluando integrar facturación electrónica por API y quieres dejar atrás el certificado, los CAF y Palena, anótate y te avisamos cuando tengas acceso.

Súmate a la lista de espera.

Mientras tanto, si ya trabajas con DTE, puedes usar el validador de XML DTE gratuito para revisar documentos que ya tengas.