Each settled sale, its fiscal document.
When your system marks a sale paid, the agent issues the document the country needs with codespar_invoice: NF-e or NFS-e in Brazil through NFe.io, CFDI in Mexico through FacturAPI, Factura in Argentina through AFIP. It reads the document's fiscal state and corrects it when needed. NFe.io has no test environment: a test key is refused, and a live project issues a real NF-e. Validating the buyer's tax ID before issuing and retrying a SEFAZ rejection are your agent's part.
One settled sale, one fiscal document.
An example with demo data: an NF-e issued through NFe.io for sale #883. In a live project the document has fiscal value; there is no test environment for it.
- The document follows the country: NF-e or NFS-e, CFDI, Factura
- The fiscal setup lives on the NFe.io company the connection points to
- A rejection comes back as the provider's error: no automatic retry or contingency
Issue the NF-e for sale #883.
Sale #883 is paid: issuing the NF-e through NFe.io for the company the connection points to.
The conversation is the easy part.
Fiscal compliance is where carts die: a missed NF-e blocks a shipment and a wrong CFOP gets a document rejected. Every country has its own document and its own rejections.
Batch invoices at month end
The agent issues the document as each sale settles
Learn a fiscal API per country
One meta tool: NF-e or NFS-e, CFDI, Factura, by provider
Correct a document in the provider's portal
action=amend issues a correction letter, or cancels and reissues
Ask the portal whether a document was authorized
action=status reads the document's fiscal state
One meta tool, a provider per country.
codespar_invoice routes to the fiscal provider the project connected: NFe.io for NF-e and NFS-e in Brazil, FacturAPI for CFDI in Mexico, AFIP for Factura in Argentina. NFe.io has no test environment: in a live project the document is real, and a test key is refused. Validating the buyer's tax ID before issuing and retrying a SEFAZ rejection are your agent's part.
Your system marks the sale paid
codespar_invoiceNF-e · NFS-e · CFDI · Factura
Connected providercodespar_invoiceThe fiscal state
Providercodespar_invoiceCorrection, or cancel and reissue
ProviderInto your archive
Your system tells the agent when a sale settles. codespar_invoice routes the issue to the provider the project connected: NFe.io (NF-e, NFS-e) issues for the company the connection points to; FacturAPI issues CFDI; AFIP issues Factura. action=status reads the document's state and action=amend corrects it in place, or cancels and reissues it. Rejections come back as the provider's error; there is no automatic retry or contingency.
The code, and what it assumes.
// Prerequisites: CODESPAR_API_KEY set to a LIVE key (csk_live_…) and an NFe.io // connection whose company holds the fiscal setup. NFe.io has no test // environment: a test key is refused, and a live key issues a real NF-e. import { CodeSpar } from "@codespar/sdk"; const session = await new CodeSpar().create("user_0000", { preset: "brazilian" }); // the agent fills codespar_invoice from the sale const run = await session.send("Issue the NF-e for sale #883: 1 t-shirt, R$ 240.00, to CNPJ 12.345.678/0001-90."); const issued = run.tool_calls.find((c) => c.tool_name === "codespar_invoice"); console.log(issued?.status, issued?.output); // later: read the document's fiscal state by its id const state = await session.execute("codespar_invoice", { action: "status", type: "nfe", invoice_id: "<id from the issue>" }); console.log(state.data);
Example with the published SDK (@codespar/sdk 0.16.11). Its prerequisites are in the comments. Compiling does not prove the integration: run it in test mode first.
codespar_invoiceIssues, reads and amends the fiscal document through the provider the project connected.
Start with a test key.
Test keys are free. Open the sandbox, connect the providers your project uses and see which tools it can call before you build.