Features

stackin brings the lifecycle of Brazilian fiscal documents into a single platform: issuance, consultation, and cancellation of NF-e and NFS-e, with direct communication to the authorizers — SEFAZ for NF-e and the national NFS-e infrastructure.

There's no simulated implementation for homologation. Requests are transmitted to the test environments provided by the authorizers themselves, keeping the integration flow close to what's used in production.

Every request belongs to a company registered with stackin. Issuer information — address, municipality, state, and digital certificate — is resolved by the platform. Your application mostly sends the operation's data — recipient, items, amounts, and other required fiscal fields — without repeating the issuer's setup on every document.

For NF-e, the platform structures and calculates the applicable tax groups, including ICMS, IPI, PIS, and COFINS, from the fiscal information provided. For NFS-e, the structure is its own, built for services, following the national model and the fields that document type requires.

Track the whole document lifecycle

The dashboard records the history of every document and lets you follow its state from submission to final result. Documents can be viewed as authorized, rejected, or cancelled, along with the events that happened during processing — when a request is rejected, the authorizer's response is available right in the history, making it easier to diagnose without manually digging through XML for the error. The same history can be followed through the API, letting your application handle each state programmatically.

Consult directly at the authorizer

Consultation lets you check a document's current state by its access key directly at the authorizer, instead of relying only on what stackin has stored — useful when your application needs to confirm a document's fiscal state before moving on to another process, like releasing an order, starting an accounting routine, or running an automation after authorization.

Cancellation

Cancellation follows the rules set by each document's authorizer. For NF-e, for instance, the justification must be at least 15 characters, per the xJust field's requirement — the request is transmitted to the authorizer and the result becomes part of the document's history. Cancellation doesn't refund the quota spent on the original issuance, since the document was already transmitted to the authorizer.

One account for everything

NF-e and NFS-e are distinct products, with different schemas, fiscal fields, and authorizers, but they share the same infrastructure inside stackin — a registered company can use the different products with the same set of credentials and the same account setup. If your operation issues both product and service documents, you don't need to maintain two integrations, two sets of API keys, or two separate environments.

A consistent API

List endpoints follow the same pagination pattern, and errors use HTTP status codes that match the operation's outcome, instead of 200 responses with errors hidden in the body. API keys follow a single authentication model — one Bearer token — but each key carries a context (sdk or api) that decides which host it's valid on: an api key authenticates on api.stackin.io, an sdk key on sdk.stackin.io, and using a key on the wrong host returns 401. See REST API for details on authentication, pagination, responses, and error codes.

REST or SDK?

All resources can be accessed directly through the REST API or the official SDKs. Use the REST API when you want to work directly with HTTP or already have your own integration layer; use an SDK when you want typed models, validation, error handling, and less infrastructure code. Either way, the destination is the same: the same API, the same documents, and the same behavior.

To learn the specific flow for each product, see NF-e issuance and NFS-e issuance.