Integración OpenFactura API en Chile: Emisión DTE Masiva desde tu Sistema

OpenFactura es el producto de Haulmer especializado en emisión de documentos tributarios electrónicos (DTE) ante el SII de Chile: boleta electrónica 39, boleta exenta 41, factura 33, factura exenta 34, nota de crédito 61, nota de débito 56 y guía de despacho 52. Funciona como facturador electrónico oficial certificado: tu empresa emite DTE válidos sin tener que certificarse directamente contra el SII ni mantener certificado digital, folios CAF, librería de firma XML-DSig o TED por su cuenta. La integración API permite que tu propio sistema (ERP, ecommerce headless, SaaS B2B, marketplace, plataforma de servicios) dispare la emisión de DTE automáticamente al confirmar una venta, sin que un humano abra el dashboard de OpenFactura. La diferencia operativa es brutal: en el modelo manual el equipo de finanzas carga ventas en OpenFactura, mientras que en el modelo integrado el DTE se emite en milisegundos al cerrar el checkout, llega por webhook a tu sistema con el PDF y XML firmados y se entrega al cliente sin intervención humana. Para empresas que emiten más de 200 DTE/mes la integración paga sola sus costos en pocas semanas de operación.

Una integración OpenFactura técnica con tu sistema parte desde $2.500.000 a $4.500.000 CLP para un alcance acotado (emisión de boleta 39 con un solo flujo, recepción de webhook de estado y almacenamiento de PDF/XML). Si necesitas factura 33 con cliente B2B, nota de crédito 61 por devoluciones y manejo de retenciones suma otros $1.500.000 a $3.000.000 CLP. Una integración avanzada con multi-empresa, emisión masiva nocturna, sincronización con BI y conciliación contra contabilidad se ubica entre $5.000.000 y $9.000.000 CLP. A esto se suma el costo recurrente del plan OpenFactura/Haulmer (que pagas a Haulmer directamente, entre $30.000 y $300.000 CLP/mes según volumen de folios) y la mantención evolutiva de la integración (mejoras menores, soporte y monitoreo) entre $200.000 y $500.000 CLP mensuales. Es una fracción del costo de una integración SII directa pero te deja amarrado al SaaS de Haulmer. La conversación correcta no es "cuánto cuesta" sino "qué tan central es la facturación para mi negocio": si la emisión de DTE es el corazón operativo conviene evaluar también una integración SII directa, descrita en /integracion-sii-boleta-electronica.

Haulmer es una suite completa de productos para pymes chilenas que incluye boleta electrónica, POS, ecommerce TUU, pago con QR, plataforma de cobros, hosting y dominios, entre otros. OpenFactura es la marca y producto específico dentro del ecosistema Haulmer enfocado exclusivamente en emisión de DTE vía API: documentación de developer, sandbox, endpoints REST estables, webhooks y herramientas pensadas para integradores técnicos. En la práctica comparten infraestructura, certificación SII y precios base, pero el público es distinto: Haulmer apunta al dueño de pyme que quiere todo en una plataforma con dashboard, OpenFactura apunta al equipo TI o desarrollador que quiere consumir solo la capa de emisión electrónica desde su propio sistema. Si tu cliente necesita además POS físico, ecommerce y pasarela de pago integrados, conviene revisar /integracion-haulmer-boleta. Si lo único que importa es disparar DTE desde tu backend con la mínima fricción posible, OpenFactura es el camino más directo. Muchos proyectos terminan usando ambos: OpenFactura como capa API de emisión y otros productos Haulmer como complementos puntuales.

Sí, OpenFactura está diseñado precisamente para emisión masiva desde sistemas integrados. La API REST acepta llamadas individuales (un DTE por request, ideal para ventas en línea con respuesta sincrónica) y también soporta envío por lotes para casos donde la emisión es diferida (por ejemplo, recurrencias mensuales de SaaS, suscripciones, facturación masiva de servicios). En e-commerce headless un patrón típico es: el checkout confirma la venta, dispara un job a la cola, el job invoca POST /dte/emit con los datos del documento, OpenFactura responde con folio, TrackID y PDF, el sistema almacena el resultado y devuelve la boleta al cliente. En operaciones de mayor volumen (más de 10 mil DTE/día) implementamos backpressure y rate limiting para no saturar la API y un fallback a contingencia interna si OpenFactura responde con error 5xx. La emisión masiva nocturna típica de marketplaces y suscripciones SaaS se ejecuta entre 1 AM y 4 AM cuando la carga al SII es menor y la latencia de OpenFactura es estable. Cubrimos volúmenes desde 100 DTE/mes hasta 500 mil DTE/mes con la misma arquitectura, ajustando solamente el plan contratado con Haulmer y el dimensionamiento del worker pool.

OpenFactura emite webhooks para los principales eventos del ciclo de vida del DTE: emisión exitosa, rechazo SII, anulación, cesión y respuesta del receptor. La confiabilidad del webhook depende tanto del proveedor como de cómo tu sistema lo consume. Por el lado de OpenFactura, el webhook se envía con reintentos automáticos y firma para validación, pero el sistema receptor debe responder 2xx en menos de 30 segundos para no gatillar reintentos en falso. Por nuestro lado implementamos el receiver con cinco patrones obligatorios: (1) endpoint público con autenticación por firma HMAC validada contra el secret configurado, (2) idempotencia por event_id para que reintentos no dupliquen efectos, (3) acuse rápido (2xx) y procesamiento asíncrono en cola interna para no superar el timeout, (4) dead-letter queue para eventos que fallen reiteradamente y alerta al equipo, y (5) reconciliación periódica contra GET /dte/{id} para detectar webhooks perdidos. Con este diseño la integración tolera caídas de OpenFactura, caídas de tu propio sistema y reintentos cruzados sin perder ni duplicar eventos. Los webhooks son confiables siempre que el cliente esté bien implementado; en integraciones que recibimos para auditar, la falla más común es la falta de idempotencia, no un problema del proveedor.

En el modelo OpenFactura los folios CAF los gestiona Haulmer en su backend: descarga, monitorea consumo, solicita nuevos al SII cuando se acercan al umbral y los asigna automáticamente al emitir cada DTE. Esto elimina el dolor más recurrente del modelo SII directo (quedarse sin folios), pero no elimina la necesidad de monitorear el flujo desde tu lado: ocasionalmente OpenFactura puede quedarse sin folios disponibles si tu emisión escala antes del aprovisionamiento, y en ese momento la API responde con error específico de "sin folios". Por eso configuramos un health-check periódico contra GET /dte/folios que valida disponibilidad por tipo de DTE y alerta al equipo si baja de cierto umbral. Para contingencia SII (cuando los servicios del SII están caídos), OpenFactura mantiene su propia cola interna y tu sistema recibe inmediatamente el folio y el TED, mientras OpenFactura se encarga de reenviar al SII en cuanto vuelva. Tu lado no debería notar la caída en el flujo de venta. Adicionalmente implementamos una contingencia secundaria desde nuestro lado: si OpenFactura mismo cae (raro pero ocurre), encolamos los DTE en una cola interna persistente con reintentos exponenciales y procesamos en cuanto el servicio vuelva, manteniendo el orden cronológico de emisión. Esa cola es la diferencia entre una venta perdida y una venta diferida en minutos.

Una integración OpenFactura de alcance acotado (un solo tipo de DTE, un flujo principal, webhooks de estado, almacenamiento de PDF/XML) toma entre 2 y 4 semanas con un equipo de 2 personas en dedicación parcial. El detalle: semana 1 levantamiento (revisión de la API, definición de eventos y mapeo de datos contra tu modelo interno), semana 2 desarrollo del cliente HTTP con manejo de errores, retries y persistencia, semana 3 implementación del webhook receiver idempotente, almacenamiento y reconciliación periódica, semana 4 pruebas en sandbox de OpenFactura, validación de casos borde (rechazos, anulaciones, retenciones, descuentos) y puesta en producción. Integraciones avanzadas con multi-empresa, emisión masiva nocturna, sincronización con BI o conciliación contable tardan 6 a 10 semanas. La ventaja de OpenFactura sobre una integración SII directa es que no necesitas el set de pruebas SII (esa parte ya la cubre Haulmer con su certificación), por lo que la integración es puramente desarrollo y QA, sin esperar aprobaciones del SII. Esto suele recortar el tiempo total a un tercio de lo que tomaría una integración SII a medida.

Depende del volumen, el control y la madurez técnica del proyecto. OpenFactura es la opción correcta cuando: (1) emites menos de 5 mil DTE/mes y el costo recurrente con Haulmer sigue siendo bajo, (2) no quieres mantener certificado digital, folios CAF y librería de firma XML-DSig en tu equipo, (3) tu sistema es relativamente nuevo o pequeño y la facturación es una capacidad accesoria, no el corazón del negocio, (4) necesitas partir rápido (semanas, no meses), y (5) valoras delegar el cumplimiento normativo a un tercero. Integración SII directa (descrita en /integracion-sii-boleta-electronica) conviene cuando: (1) emites volumen alto y el costo por folio del SaaS empieza a doler, (2) tu sistema es crítico y no puede depender de un proveedor externo para emitir DTE, (3) necesitas multi-empresa con razones sociales independientes o lógicas tributarias muy específicas, (4) quieres ownership total del dato fiscal y de la cola de contingencia, o (5) ya tienes equipo TI con experiencia en SII y prefieres no introducir un tercero. Una buena estrategia para muchos clientes es partir con OpenFactura para acelerar time-to-market y migrar a integración SII directa cuando el volumen lo justifique. Esa migración es ordenada porque los modelos de DTE son los mismos.