NFC-e issuance

Every state. Issuance works in any state: Sudrel prepares your company's state in minutes, from the registration, with no action from you. Where the text mentions Bahia, it is the state of the examples and of the rules already detailed.

NFC-e is the retail invoice: an in-person sale to a final consumer, within the state. At Sudrel it is another model of the same issuance as NF-e: same certificate, same layout 4.00, same guarantees (the number is reserved in the same transaction that creates the invoice, the key never changes, and an invoice that may have reached SEFAZ is only resolved by querying the key). The sandbox (sdr_test_) issues for real in SEFAZ homologação, with no fiscal value; the sdr_live_ key issues in production.

Before the first NFC-e

1. Register (caixa). Every NFC-e comes from a register, and each register has its own series (0 to 889, unique within the company). Register it with POST /v1/caixas using the identifier your system uses (LOJA1-CX02). The sandbox has its own registers.
2. Products and tax profile. In calcular mode (the NFC-e default) Sudrel calculates taxes from the registered product; see Products and tax engine.
3. CSC (optional). The QR Code goes out in version 3, which does not use the Código de Segurança do Contribuinte. If the state's SEFAZ refuses version 3 (rejection 407), Sudrel rebuilds the invoice in version 2, which needs the CSC: register it at PUT /v1/nfce/csc/{empresa_id} (id_csc and csc, as SEFAZ delivered them). The CSC is stored encrypted and never comes back in a response or a log.
4. Readiness. GET /v1/nfce/prontidao/{empresa_id} says what is missing, item by item. The list of items grows with the next phases.

The sale

POST /v1/nfce
Idempotency-Key: CUPOM-000123
Prefer: wait=15

{
  "empresa_id": "0b7e6a52-3c1d-4f8e-9a20-5d4c3b2a1f00",
  "referencia": "CUPOM-000123",
  "caixa": "LOJA1-CX02",
  "itens": [{ "produto": "CAM-1", "quantidade": 2, "valor_unitario": 39.90 }],
  "pagamentos": [{ "forma": "dinheiro", "valor": 100 }]
}

The response comes in the same call: 201 with the authorized NFC-e, the qr_code, the url_consulta, the troco (change: how much the payments exceed the total, calculated) and the receipt links. The Idempotency-Key is required: the register repeats the request when the network drops, and Sudrel returns the same invoice instead of issuing another.

• modo: calcular (default), informado (each item's taxes come ready, as in NF-e) or conferir.
• consumidor: { "documento", "nome", "email" }, optional. In BA it is required from R$ 500,00 (RICMS/BA, art. 107-D, § 2º): without it, the sale comes back 422 nfce_consumidor_obrigatorio before any number is used.
• Card and Pix carry the card group: without cartao, it goes out as a POS without integration; with "cartao": { "integrado": true, "cnpj_credenciadora", "autorizacao" }, as TEF.

Sudrel checks the modelo 65 rules before sending and responds with the field and the rule: CFOP (5101, 5102, 5103, 5104, 5115, 5405, 5656, 5667), ICMS CST (00, 20, 40, 41, 60) and CSOSN (102, 103, 300, 400, 500) with the matching CFOP, no IPI, no freight and in-person sales only.

Receipt

GET /v1/nfce/{id}/danfe returns the 80 mm DANFE NFC-e as a PDF, in the layout of the Manual de Padrões DANFE NFC-e e QR Code (v6.0), with the QR Code and the homologação message when applicable. With ?formato=texto, the same receipt in 48 columns for a thermal printer (the QR Code goes as the qr_code text, which the printer draws). POST /v1/nfce/{id}/envio e-mails the receipt and the XML to the consumer.

Cancellation

POST /v1/nfce/{id}/cancelamento, with a justificativa of 15 to 255 characters, until cancelavel_ate: 30 minutes after authorization in BA (RICMS/BA, art. 107-H, I). After that the response is 422 cancelamento_fora_do_prazo, with the path the state's law provides; in BA there is no late (extemporâneo) cancellation of NFC-e. Cancellation has its own queue, separate from issuance: a sales peak does not hold up a cancellation.

States and events

The same states as NF-e (autorizada, rejeitada, denegada, cancelada, descartada, transmitindo, aguardando_confirmacao). Webhooks: NFCE_AUTORIZADA, NFCE_REJEITADA, NFCE_DENEGADA, NFCE_CANCELADA, NFCE_DESCARTADA, NFCE_DESCARTE_PROXIMO and NFCE_ENVIO_PAUSADO, with the whole NFC-e in dados. The lists of states and events grow: handle unknown values without breaking.

NFC-e and NF-e are separate in the API: GET /v1/nfe does not list NFC-e, and GET /v1/nfce/{id} does not find an NF-e, even with the right id. The referencia and the Idempotency-Key are unique per model.

Sources: MOC 7.0 (Anexo I, modelo 65 rules), Manual de Padrões DANFE NFC-e e QR Code v6.0, NT 2025.001 v1.03 (QR Code version 3), RICMS/BA (Decreto 13.780/2012).