Solutions

Most integrations with stackin start with a simple need: issue a product invoice, issue a service invoice, or correctly handle the tax data required for issuance. stackin abstracts the complexity of that process into a single typed API — you work with structured data while the platform handles authorizer communication (document generation, signing, transmission, and response handling), with no manual XML, no signing infrastructure to build, and no per-authorizer integrations to maintain.

Issue NF-e

Use NF-e for operations involving products and goods — provide the operation's data, the products, and their tax classification (NCM, CFOP, CSOSN/CST), and stackin prepares and transmits the document to the SEFAZ authorizer, covering ICMS, IPI, PIS, and COFINS. See Issue NF-e for the full fields and NF-e issuance for how that API surface works.

Issue NFS-e

Use NFS-e for service operations — the integration follows Brazil's national NFS-e standard (ADN), so it works the same for any municipality, no per-city integration. See Issue NFS-e for the full fields and NFS-e issuance for how that API surface works.

Tax passthrough

Tax handling happens automatically inside NF-e issuance itself, from the classification codes provided in the operation — no dedicated tax engine to maintain. See Tax passthrough for which values can be calculated, provided, or overridden.

One integration, different documents

You don't have to implement everything at once: a company that only sells products can start with NF-e, a services company can integrate only NFS-e, and operations that do both use both flows through the same API. As the operation grows, new capabilities come in without rebuilding the fiscal integration from scratch — see Features for how the REST API and SDKs fit into this.