Estado del proyecto
dte-sdk está en desarrollo activo y no está listo para producción. Esta página dice, sin redondear hacia arriba, qué versión está dónde, qué partes se probaron contra el SII real, qué falta antes del primer lanzamiento recomendado para producción y qué pruebas y controles cuidan el código mientras tanto.
No se recomienda su uso en producción hasta la 1.0.0. Hasta entonces la API puede cambiar en cualquier versión, y buena parte de lo que describe esta documentación todavía no se ha probado contra el SII real. La tabla de abajo dice exactamente qué partes sí.
Versiones#
| Versión | Qué es |
|---|---|
0.8.0 | La versión más reciente en npm, publicada el 11 de noviembre de 2026, y la que documenta este sitio. Lee un documento pagado al contado. Cuando una factura se emite pagada al contado, el SII le registra PAG ("DTE Pagado al Contado") al recibirla, y el registro de aceptación y reclamo rechaza desde entonces cualquier aceptación, reclamo o recibo de mercaderías sobre ella con el código 27. receiverAnswer leía PAG como algo que no cambia nada, así que un documento así se leía como pending con ocho días para reclamar, y como tacitlyAccepted pasados esos días, invitando a una respuesta que el SII rechaza. Ahora responde el nuevo paidInCash, con claimDeadline en null, y receiverStatus lee un último PAG como paidInCash donde decía unknown. El código 27 se suma a CLAIM_RESPONSE_CODES. ReceiverAnswer y ReceiverStatus ganan el caso, así que un switch exhaustivo sobre cualquiera de los dos lo necesita, y una app que ofrece las acciones del registro no ofrece ninguna sobre paidInCash (revisa receiverAnswer). Un documento emitido gratuito (Sin costo) se rechaza con el mismo código, pero todavía no se ha visto el listado de eventos de uno, así que se lee como antes. Instálala con npm install dte-sdk. |
0.7.0 | Publicada el 10 de noviembre de 2026: resuelve los vacíos que encontró una app mientras se construía sobre las versiones anteriores. Los flujos de folios de dte-sdk/portal son más seguros, los archivos CAF se leen en la codificación que declaran, parseCaf chequea que la llave privada sea el par de la pública, y receiverAnswer recibe el resultado completo de listClaimEvents, así que una consulta de eventos fallida se lee como el nuevo unknown, nunca como un documento aceptado por ley. Si llevas un registro de folios sobre archivos CAF en disco, las entradas de algunos archivos pasan a un alcance nuevo (revisa Archivos CAF). |
0.6.0 | Publicada el 10 de noviembre de 2026: los otros flujos de folios de dte-sdk/portal conservan lo que ya tienen cuando falla un paso posterior, como lo hace requestCafInBatches desde la 0.5.0: annulFolios devuelve lo que el SII ya anuló, reobtainFolios los CAF que ya descargó y requestCafExact el knownAnnulled de su anulación, cada uno con failure, y un flujo cortado registra el error original con cada texto tachado. |
0.5.0 | Publicada el 9 de noviembre de 2026: requestCafInBatches de dte-sdk/portal conserva los CAF que ya tiene cuando falla un viaje posterior, y los devuelve con complete: false y el campo nuevo failure, donde antes lanzaba y se perdían, y createDirectoryFolioRegistry de dte-sdk/node escribe su libro solo para el dueño. |
0.4.0 | Publicada el 9 de noviembre de 2026: agrega a dte-sdk la verificación de documentos recibidos, las llaves con que el SII firma los CAF y los tipos de documento del registro de reclamos como lista, y endurece dos chequeos: una firma verifica solo en la forma que calcula el SDK, y parseCaf rechaza un archivo con más de un <CAF o </CAF, o con un DOCTYPE. |
0.3.0 | Publicada el 8 de noviembre de 2026: agrega a dte-sdk/portal la verificación de actividades, cuya lectura sigue inestable, y el catálogo de los documentos que acreditan una actividad. |
0.2.0 | Publicada el 8 de noviembre de 2026: agrega a dte-sdk/portal el catálogo de los códigos de documento del registro de compras y ventas. |
0.1.0 | Publicada el 7 de noviembre de 2026: el primer lanzamiento con una API pública. |
0.x | Los lanzamientos anteriores a la 1.0.0 salen a medida que se termina el trabajo, sin esperar las pruebas contra el SII real. Cualquiera puede cambiar la API: fija la versión y lee el changelog antes de cambiarte. |
canary | La rama de desarrollo en GitHub, donde se arma el próximo lanzamiento. |
1.0.0 | El primer lanzamiento recomendado para producción, una vez que cada área se haya probado contra el SII real. |
Los lanzamientos salen de un pull request de release propio y los publica el CI al subir una etiqueta de versión, con procedencia de npm. Fusionar en canary nunca publica. Revisa RELEASING.md.
Qué se probó contra el SII real#
Cada área está probada contra respuestas sintéticas del SII, con una barrera de cobertura de 100 % en CI. Esas pruebas no pueden mostrar cómo responde el SII real, así que esta tabla dice qué lo ha enfrentado hasta ahora en cada uno de los ambientes del SII: producción y certificación (maullin). "No consta" significa que no se ha anotado ninguna ejecución, no que el SII haya rechazado una; una raya significa que el SII lo ofrece solo en el otro ambiente.
| Área | Entrada | Producción | Certificación (maullin) |
|---|---|---|---|
| Documentos, timbres, firmas y sobres | dte-sdk | Aún no enviados | Aún no enviados |
| Verificación de documentos recibidos | dte-sdk | Un chequeo local, sin llamar al SII: aún no se ejecuta sobre un documento que haya enviado un proveedor. Las pruebas firman CAF de prueba con una llave del SII de prueba, y las llaves del propio SII se probaron con CAF reales solo en un chequeo a mano | Igual que en producción |
| Servicios web: semilla y token, SOAP | dte-sdk | Sí, el 9 y el 10 de noviembre de 2026: un token por una semilla firmada con el certificado, reutilizado entre llamadas | Aún no se ejecuta (issue 8) |
| Servicios web: semilla y token, REST de boletas | dte-sdk | Aún no se ejecuta | Aún no se ejecuta (issue 8) |
| Servicios web: envíos y su estado | dte-sdk | Aún no se ejecutan | Aún no se ejecutan (issue 8) |
| Servicios web: registro de aceptación o reclamo | dte-sdk | Sí, el 9 y el 10 de noviembre de 2026, sobre una factura recibida (tipo 33): registerClaim respondió 0 para ERM y luego para ACD; listClaimEvents respondió 16 (sin eventos) antes y 15 (los dos eventos) después; queryReceptionDate dio la fecha de recepción y receiverAnswer el plazo. El 11 de noviembre de 2026, registerClaim respondió 27 para ACD sobre una factura pagada al contado, cuyos eventos listaban solo PAG. Los reclamos (RCD, RFP, RFT) y queryTransferable aún no se ejecutan | Aún no se ejecuta (issue 8) |
| Registro público de emisores autorizados | dte-sdk | No consta | No consta |
| Libros del SII | dte-sdk | Aún no enviados; en las pruebas validan contra los esquemas oficiales | Aún no enviados |
| Sesión del portal | dte-sdk/portal | Sí, el 9 y el 10 de noviembre de 2026: ingreso con certificado y la sesión reutilizada entre lecturas, para una empresa no inscrita como emisor | No consta |
| Datos de la empresa y páginas de rechazo | dte-sdk/portal | No consta | No consta |
| Folios y solicitud de CAF | dte-sdk/portal | Aún no se ejecutan: necesitan una empresa inscrita | Aún no se ejecutan: necesitan una empresa inscrita; las pruebas reproducen las páginas que este ambiente le mostró a una |
| Registro de compras y ventas: lecturas | dte-sdk/portal | Sí, el 9 y el 10 de noviembre de 2026, para una empresa con una factura recibida: fetchRegisterSummary, listPeriodDocuments, fetchPurchaseDocument y listPurchaseTypes respondieron con sus filas. createdAt (det_fec_creacion) llega en milisegundos desde la época Unix. Justo después de un reclamo, la llamada de resumen del listado respondió HTTP 503 dos veces, y en la lectura siguiente respondió | No consta |
| Registro de compras y ventas: escrituras, respaldo MIPYME | dte-sdk/portal | Aún no se ejecutan | Aún no se ejecutan |
| Verificación de actividades | dte-sdk/portal | Leída el 9 de noviembre de 2026 para una verificación condicionada, pendiente de acreditación, como antes para una pendiente; una aprobada aún no se ha visto, así que la lectura sigue inestable | — |
| Sets de certificación, ejecutor, intercambio y envío de las muestras | dte-sdk/portal | — | Aún no se ejecutan; en las pruebas las respuestas de intercambio validan contra los esquemas oficiales |
| Certificación de boletas | dte-sdk/portal | — | Aún no se ejecuta: necesita una empresa inscrita en la aplicación de boletas; en las pruebas el sobre de boletas y el reporte de consumo de folios validan contra los esquemas oficiales |
| Muestras impresas | dte-sdk/pdf | — | Aún no revisadas por el SII |
Las ejecuciones en producción del 9 y el 10 de noviembre de 2026 vinieron de una aplicación construida sobre dte-sdk, para una sola empresa, con la 0.3.0 y luego con la 0.4.0. Ejecuciones anteriores, cuyo ambiente no quedó anotado, respondieron el ingreso y la salida del portal, los datos del contribuyente y las páginas de rechazo para una empresa no inscrita como emisor, y las solicitudes de solo lectura del registro de compras y ventas para una empresa sin documentos.
Qué significa esto para ti: los documentos y las firmas que arma el SDK siguen los formatos del SII y se contrastan con sus esquemas donde las pruebas los tienen, pero ningún sobre armado por este SDK se ha subido todavía al SII, y el comportamiento del SII en las páginas y servicios que la tabla no marca como probados, en el ambiente que uses, es una lectura de cómo funciona, no una observación.
Falta antes de la 1.0.0#
Probar cada área contra el SII real, empezando por las pruebas en vivo que se siguen en el issue 8. La tabla de arriba marca qué áreas todavía no se han enfrentado a él. También quedan abiertas las consultas de detalle del registro de compras y ventas, que hay que comparar con respuestas reales (issue 14), y las mejoras del runner de certificación que se dejaron para después de la primera certificación real (issue 29).
Fuera de alcance#
Esto no forma parte del SDK:
- Documentos de exportación (110, 111 y 112).
- Boletas de honorarios.
- La cesión de facturas (AEC).
- Los formularios F29 y F22.
- El correo de intercambio.
- La validación XSD completa. El SDK arma los documentos según los esquemas del SII y las pruebas validan libros, respuestas de intercambio y el sobre de boletas contra los XSD oficiales, pero no valida contra el XSD cada documento que emites en tiempo de ejecución.
Cómo se cuida la calidad#
El CI corre en cada pull request y en cada push a canary. Estos son los controles y lo que protege cada uno:
| Control | Qué protege |
|---|---|
| Barrera de cobertura de 100 % | Las sentencias, ramas, funciones y líneas de src/ deben estar cubiertas por pruebas; el CI falla ante cualquier baja. |
| Pruebas de propiedades | Los totales, el manejo de texto, el viaje de ida y vuelta del códec de documentos, la normalización de RUT y los totales de los libros se comprueban con entradas generadas, no solo con ejemplos elegidos a mano. |
| Pruebas a nivel de tipos | Los tipos públicos están probados, de modo que un cambio que rompe lo que escriben los consumidores hace fallar una prueba y no la compilación de tu proyecto. |
| Pruebas de humo del dist | Se carga el paquete compilado, no el código fuente, entrada por entrada. Comprueban que cargar no evalúa ningún módulo node:, que la raíz se empaqueta para el navegador, que los errores cruzan entre entradas y que los consumidores con nodenext, bundler y node10 obtienen tipos reales. El CI además importa cada entrada en Bun y Deno. |
| Validación de esquemas en las pruebas | Los tres libros del SII, las respuestas de intercambio (respuesta de recepción, recibos y aprobación comercial) y el sobre de boletas EnvioBOLETA se validan contra los esquemas oficiales del SII. |
| Presupuestos de tamaño | size-limit hace fallar la compilación si una entrada supera su presupuesto: 36 kB, 8 kB, 76 kB y 11 kB para las entradas raíz, node, portal y pdf (revisa Puntos de entrada). |
| Escaneo de datos reales | npm run scan falla si un archivo versionado contiene un RUT fuera de una lista corta de valores de documentación, una ruta local de máquina o un archivo con aspecto de secreto, como un .pfx o .pem fuera de los fixtures de prueba. El repositorio es público y nunca debe contener a un contribuyente real. |
| Matriz de Node y lint | Las pruebas corren en Node 22 y 24, y ESLint y Prettier corren en cada cambio. |
El repositorio también tiene una configuración de pruebas de mutación, que se ejecuta a mano como revisión periódica y no como barrera de CI, y una prueba de humo opcional contra el ambiente de certificación del SII, que necesita un certificado real y no forma parte del CI.
Sigue el avance#
- GitHub: arrowsw/dte-sdk. Los issues y los pull requests están abiertos; las pruebas en vivo están en el issue 8.
- Changelog: CHANGELOG.md. Lo que aún no se publica está bajo
Unreleased. - npm: dte-sdk, con cada versión publicada y su procedencia.
- Reportes de seguridad: revisa SECURITY.md y la página de Seguridad.