Project status
dte-sdk is under active development and is not ready for production. This page says, without rounding up, which version is where, which parts have met the real SII, what is left before the first release recommended for production, and what tests and checks guard the code in the meantime.
Use in production is not recommended until 1.0.0. Until then the API can change in any release, and much of what these docs describe has not met the real SII yet. The table below says exactly which parts have.
Versions#
| Version | What it is |
|---|---|
0.8.0 | The latest version on npm, published on 11 November 2026, and the one this site documents. It reads a document paid in cash. When an invoice is issued as paid in cash, the SII registers PAG ("DTE Pagado al Contado") on it as it receives it, and the acceptance and claim registry then refuses any acceptance, claim or goods received on it with code 27. receiverAnswer read PAG as changing nothing, so such a document read as pending with eight days to claim, and as tacitlyAccepted after them, inviting an answer the SII refuses. It now answers the new paidInCash, with claimDeadline null, and receiverStatus reads a last PAG as paidInCash where it said unknown. Code 27 joins CLAIM_RESPONSE_CODES. ReceiverAnswer and ReceiverStatus gain the case, so an exhaustive switch on either needs it, and an app that offers the registry's actions offers none on paidInCash (see receiverAnswer). A document issued as free (Sin costo) is refused with the same code, but no events listing of one has been seen, so it reads as before. Install it with npm install dte-sdk. |
0.7.0 | Published on 10 November 2026: it settles the gaps an app found while it was built on the earlier releases. The folio flows of dte-sdk/portal are safer, CAF files are read in the encoding they declare, parseCaf checks that the private key pairs the public one, and receiverAnswer takes the whole result of listClaimEvents, so a failed events query reads as the new unknown, never as a document accepted by law. If you keep a folio registry over CAF files on disk, the entries of some files move to a new scope (see CAF files). |
0.6.0 | Published on 10 November 2026: the other folio flows of dte-sdk/portal keep what they already hold when a later step fails, as requestCafInBatches does since 0.5.0: annulFolios returns what the SII already annulled, reobtainFolios the CAFs it already downloaded and requestCafExact the knownAnnulled of its annulment, each with failure, and a flow cut short logs the original error with every text redacted. |
0.5.0 | Published on 9 November 2026: requestCafInBatches in dte-sdk/portal keeps the CAFs it already holds when a later trip fails, returning them with complete: false and the new field failure, where before it threw and they were lost, and createDirectoryFolioRegistry in dte-sdk/node writes its ledger for the owner only. |
0.4.0 | Published on 9 November 2026: it adds to dte-sdk the verification of received documents, the SII's CAF keys and the claim registry's document types as a list, and makes two checks stricter: a signature verifies only in the form the SDK computes, and parseCaf refuses a file with more than one <CAF or </CAF, or with a DOCTYPE. |
0.3.0 | Published on 8 November 2026: it adds the activity verification to dte-sdk/portal, its read still unstable, and the catalog of the documents that accredit an activity. |
0.2.0 | Published on 8 November 2026: it adds the catalog of the purchase and sales register's document codes to dte-sdk/portal. |
0.1.0 | Published on 7 November 2026: the first release with a public API. |
0.x | Releases before 1.0.0 come out as the work lands, without waiting for the runs against the real SII. Any of them can change the API: pin the version and read the changelog before you move. |
canary | The development branch on GitHub, where the next release is built. |
1.0.0 | The first release recommended for production, once every area has run against the real SII. |
Releases are cut from a dedicated release pull request and published by CI when a version tag is pushed, with npm provenance. Merging to canary never publishes. See RELEASING.md.
What has met the real SII#
Every area is tested against synthetic SII answers, with a 100 % coverage gate in CI. Those tests cannot show how the real SII answers, so this table says what has met it so far, in each of the SII's environments: production and certification (maullin). "Not recorded" means no run has been written down, not that the SII refused one; a dash means the SII offers it in the other environment only.
| Area | Entry | Production | Certification (maullin) |
|---|---|---|---|
| Documents, stamps, signatures and envelopes | dte-sdk | Not sent yet | Not sent yet |
| Verification of received documents | dte-sdk | A local check with no SII call: not run on a document a supplier sent yet. The tests sign test CAFs with a test SII key, and the SII's own keys met real CAFs only in a check by hand | Same as production |
| Web services: seed and token, SOAP | dte-sdk | Yes, on 9 and 10 November 2026: a token for a seed the certificate signed, reused between calls | Not run yet (issue 8) |
| Web services: seed and token, receipts REST | dte-sdk | Not run yet | Not run yet (issue 8) |
| Web services: uploads and their status | dte-sdk | Not run yet | Not run yet (issue 8) |
| Web services: acceptance and claim registry | dte-sdk | Yes, on 9 and 10 November 2026, on one received invoice (type 33): registerClaim answered 0 for ERM and then for ACD; listClaimEvents answered 16 (no events) before and 15 (both events) after; queryReceptionDate gave the reception date and receiverAnswer the deadline. On 11 November 2026, registerClaim answered 27 for ACD on an invoice paid in cash, whose events listed PAG alone. The claims (RCD, RFP, RFT) and queryTransferable not run yet | Not run yet (issue 8) |
| Public registry of authorized issuers | dte-sdk | Not recorded | Not recorded |
| SII books | dte-sdk | Not sent yet; they validate against the official schemas in the tests | Not sent yet |
| Portal session | dte-sdk/portal | Yes, on 9 and 10 November 2026: certificate login and the session reused between reads, for a company not enrolled as an issuer | Not recorded |
| Company data and the refusal pages | dte-sdk/portal | Not recorded | Not recorded |
| Folios and CAF requests | dte-sdk/portal | Not run yet: they need an enrolled company | Not run yet: they need an enrolled company; the tests replay the pages this environment served to one |
| Purchase and sales register: reads | dte-sdk/portal | Yes, on 9 and 10 November 2026, for a company with one received invoice: fetchRegisterSummary, listPeriodDocuments, fetchPurchaseDocument and listPurchaseTypes answered with its rows. createdAt (det_fec_creacion) comes as milliseconds since the epoch. Right after a claim, the listing's summary call answered HTTP 503 twice and answered on the next read | Not recorded |
| Purchase and sales register: writes, MIPYME backup | dte-sdk/portal | Not run yet | Not run yet |
| Activity verification | dte-sdk/portal | Read on 9 November 2026 for a conditioned verification pending accreditation, as before for a pending one; an approved one not seen yet, so the read stays unstable | — |
| Certification sets, runner, exchange and upload of the samples | dte-sdk/portal | — | Not run yet; the exchange answers validate against the official schemas in the tests |
| Certification of receipts (boletas) | dte-sdk/portal | — | Not run yet: it needs a company enrolled in the receipts application; the receipts envelope and the folio consumption report validate against the official schemas in the tests |
| Printed samples | dte-sdk/pdf | — | Not reviewed by the SII yet |
The production runs of 9 and 10 November 2026 came from an application built on dte-sdk, for one company, on 0.3.0 and then 0.4.0. Earlier runs, whose environment wasn't written down, answered the portal's login and logout, the taxpayer data and the refusal pages for a company not enrolled as an issuer, and the register's read-only requests for a company with no documents.
What that means for you: the documents and signatures the SDK builds follow the SII's formats and are checked against its schemas where the tests have them, but no envelope built by this SDK has been uploaded to the SII yet, and the SII's behaviour in the pages and services the table does not mark as met, in the environment you use, is a reading of how it works, not an observation.
Still to come before 1.0.0#
Running every area against the real SII, starting with the live runs tracked in issue 8. The table above marks which areas have not met it yet. Also open: the detail calls of the purchase and sales register, to be compared against real answers (issue 14), and the improvements of the certification runner set aside until the first real certification has passed (issue 29).
Out of scope#
These are not part of the SDK:
- Export documents (110, 111 and 112).
- Fee receipts (boletas de honorarios).
- The assignment of invoices (AEC).
- Forms F29 and F22.
- The exchange e-mail.
- Full XSD validation. The SDK builds documents to the SII's schemas, and the tests validate books, exchange answers and the receipts envelope against the official XSDs, but it does not validate every document you issue against the XSD at run time.
How quality is guarded#
CI runs on every pull request and on every push to canary. These are the guards, and what each one protects:
| Guard | What it protects |
|---|---|
| 100 % coverage gate | Statements, branches, functions and lines of src/ must all be covered by tests; CI fails on any drop. |
| Property tests | Totals, text handling, the document codec round trip, RUT normalization and book totals are checked against generated inputs, not only hand-picked examples. |
| Type-level tests | The public types are tested, so a change that breaks what consumers write fails a test, not a build in your project. |
| Dist smoke tests | The built package, not the source, is loaded entry by entry. They check that loading evaluates no node: module, that the root bundles for the browser, that errors cross entries and that consumers on nodenext, bundler and node10 get real types. CI also imports every entry on Bun and Deno. |
| Schema validation in the tests | The three SII books, the exchange answers (reception response, receipts and commercial approval) and the EnvioBOLETA receipts envelope are validated against the official SII schemas. |
| Size budgets | size-limit fails the build if an entry grows past its budget: 36 kB, 8 kB, 76 kB and 11 kB for the root, node, portal and pdf entries (see Entry points). |
| Scan for real data | npm run scan fails if a tracked file holds a RUT outside a short allow-list of documentation values, a local machine path, or a secret-looking file such as a .pfx or .pem outside the test fixtures. The repository is public and must never carry a real taxpayer. |
| Node matrix and lint | The tests run on Node 22 and 24, and ESLint and Prettier run on every change. |
The repository also has a mutation-testing configuration, run by hand as a periodic check and not as a CI gate, and an opt-in smoke test against the SII certification environment, which needs a real certificate and is not part of CI.
Follow the progress#
- GitHub: arrowsw/dte-sdk. Issues and pull requests are open; the live runs are in issue 8.
- Changelog: CHANGELOG.md. What is not released yet is under
Unreleased. - npm: dte-sdk, with every published version and its provenance.
- Security reports: see SECURITY.md and the Security page.