Portaria 363/2010 · certificação em curso · API · Portugal

A AT é meses de trabalho.
Para ti, é um POST.

ATCUD, QR, SAF-T, séries gap-free e assinatura digital — tratados pelo motor construído para a Portaria 363/2010. FazesPOST /v1/documents/invoices e recebes a fatura, o PDF e o webhook. NIF/VIES, moradas CTT e MCP + Skills incluídos.

  • <10 min do zero ao 1.º FT
  • sandbox ilimitada grátis
  • chaves test/live
CobreFT · FS · FRNC · NDRecibosGuias de transporteSAF-TNIF / VIESMoradas CTTWebhooksQR + ATCUD

nodex Connect

Liga o que já usas. As faturas — e a manutenção — ficam connosco.

O Stripe muda a API. A AT muda as regras. Esse trabalho costumava ser teu — agora é nosso. Ligas a fonte uma vez (uma chave, um secret) e o mapa pagamento → fatura fica feito, testado e mantido por nós.

a tua fonte
StripeWooCommerceShopify · em breveMB WAY · em breve
nodexemite · assina · comunica à AT
recebesFatura-recibo · PDF · ATCUD · webhook

Autoriza uma vez, esquece

Ligas a fonte e o NIF/série. A partir daí, cada cobrança vira fatura sozinha — deduplicada pelo id do evento.

Muda a fonte ou a AT? Mantemos nós

O mapa evolui do nosso lado. Não tocas em código quando o Stripe ou a lei mudam.

Seguro por defeito

Um orquestrador por conta, segredos cifrados, assinatura verificada em cada entrega — nunca emites a mesma fatura duas vezes.

Preferes controlar tudo? Usa a API diretamente — o Connect é o atalho, não a única porta.

Showcase ao vivo

O fluxo, passo a passo

Vês o caminho que um request percorre — do body validado à fatura emitida com ATCUD. Encenação fiel: os payloads são tipados pelos contratos reais da API, sem backend a fingir.

live showcase
  1. client
    POST /v1/documents/invoices

    O cliente envia só o customer + lines. Número, série, ATCUD e data são do sistema.

  2. gateway
    auth · idempotency · zod

    API key verificada, Idempotency-Key dedupada, body validado (strict) contra os contratos.

  3. fiscal
    encaminha para o motor

    document-service encaminha para o motor nodex (o backend certificado). Um documento = um só backend.

  4. postgres
    série → ATCUD → assinatura → write-once

    Numa transação: contador gap-free da série, ATCUD, assinatura + hash-chain, audit append-only e outbox.

  5. api
    200 issued · FT 2026/1

    Resposta síncrona com o documento emitido e o pdf_url. Caminho lento devolveria pending.

  6. webhooks
    document.issued →

    Evento fat assinado (HMAC) entregue via fila, com retries até ~72h e replay manual.

request body
{
  "customer": {
    "name": "Padaria Aurora, Lda.",
    "tax_id": "501442600",
    "country": "PT",
    "email": "geral@padariaaurora.pt"
  },
  "lines": [
    {
      "description": "Consultoria de integração — Junho",
      "quantity": "1",
      "unit_price": "1500.00",
      "tax_rate": 23
    }
  ]
}
response

Corre o request para ver a fatura emitida.

O request que farias

Envias o essencial; o nodex trata de série, numeração, ATCUD, assinatura e PDF. Idempotente por Idempotency-Key.

curl
curl -X POST https://api.nodex.glie.ai/v1/documents/invoices \
  -H "Authorization: Bearer nx_test_…" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
  "customer": {
    "name": "Padaria Aurora, Lda.",
    "tax_id": "501442600",
    "country": "PT",
    "email": "geral@padariaaurora.pt"
  },
  "lines": [
    {
      "description": "Consultoria de integração — Junho",
      "quantity": "1",
      "unit_price": "1500.00",
      "tax_rate": 23
    }
  ]
}'

Validação

Valida um NIF agora

O checksum (módulo 11) corre no teu browser — é o mesmo passoformat_valid da API. O estado oficial vem do VIES, consultado server-side. Honesto: nunca inventamos um "válido".

Checksum corrido aqui no browser (é o passo format_valid da API). O estado oficial e o nome/morada vêm do VIES, consultado server-side por GET /v1/customers/validate — nunca inventamos um estado oficial.

POST https://your-app.com/webhooks

à espera de eventos…

Simulação do feed. Na realidade: entrega via fila Postgres, retries até ~72h, replay manual e GET /v1/events para o histórico.

Eventos em tempo real

Webhooks que não falham em silêncio

Cada mudança de estado emite um evento fat, assinado com HMAC e entregue via fila com retries até ~72h. Replay manual e histórico consultável em GET /v1/events.

No mesmo motor, já em código

Mais do que faturas

Pagamentos, open banking, moradas, validações — a parte operacional que todo o software português volta a construir, pronta a usar na mesma API.

fiscal

Doze tipos de documento

FT, FS, FR, NC, ND, recibos, orçamentos e as cinco guias de transporte — todos assinados, numerados e no SAF-T. Uma só API.

motor

Motor próprio, sem intermediários

A emissão, a assinatura RSA e o hash-chain por série correm no nosso motor — não em cima da API de terceiros. A chave privada vive num KMS, nunca no servidor.

saf-t

SAF-T que passa o validador da AT

A exportação SAF-T (PT) 1.04_01 é validada contra o validador oficial da AT — no nosso CI, em cada build.

validação

NIF + VIES, a sério

Checksum local + VIES oficial da UE com cache. Quando o VIES cai, devolvemos unknown retryable — nunca um falso "válido".

moradas

Moradas oficiais CTT

CP7 validado contra o dataset oficial, autocomplete de ruas (pg_trgm) e passthrough para moradas estrangeiras.

eventos

Webhooks fiáveis

Eventos assinados (HMAC), entrega via fila com retries até ~72h, replay manual e feed consultável em GET /v1/events.

pagamentos

Pagamentos & open banking

Referências Multibanco, MB WAY e SEPA + PSD2 (Berlin Group) para saldos e movimentos. Sandbox funcional hoje; a SIBS liga-se com credenciais, não com fé.

multi-empresa

Uma conta, N empresas

Constróis um SaaS? Cada NIF isolado por Row-Level Security fail-closed, da série ao SAF-T — multi-tenant nativo, não um bolt-on.

dados

Dados que não mentem

Dinheiro em decimal-string, numeração gap-free, idempotência exactly-once, audit append-only com hash-chain, RLS por tenant e ambientes test/live isolados.

Quando a lei muda — ou a API de um terceiro — isto atualiza do nosso lado, não do teu.

Preços

Grátis até usares a sério. Depois, cêntimos.

O mercado cobra €6–24/mês por escalões — e o plano grátis típico dá 1 documento. Nós damos-te 100 por mês, para sempre, e cobramos só o que passa disso.

Grátis€0/para sempre

Para protótipos, side projects e negócios pequenos. Sem cartão.

  • 100 documentos/mês
  • Sandbox ilimitada
  • Todos os tipos de doc + ATCUD/QR/SAF-T
  • NIF/VIES, moradas CTT, webhooks
  • MCP + Skills
Obter API key
EnterpriseCustom

Para volume e plataformas.

  • SLA e suporte dedicado
  • PDF com o teu logótipo
  • Rate limits à medida
  • Faturação por volume negociada
Falar connosco

Tudo incluído em todos os níveis — cancelamento, séries, isenção B2B-UE, SAF-T. A compliance nunca é upsell.Qual é o truque? ↓

Para agentes · MCP · llms.txt

Fizemos o vanilla para tu — e a tua AI — não terem de fazer.

O teu agente lê os docs (llms.txt e llms-full.txt, gerados do contrato real), fala com o servidor MCP oficial — sete ferramentas — e escreve a integração à primeira. Diz-lhe: "emite uma fatura-recibo de 1000 € + IVA ao cliente 501442600". Ele sabe o resto.

Emite a tua primeira fatura

Sandbox ilimitada, sem custo. Do zero ao FT em minutos.

A resposta honesta

Qual é o truque?

É a pergunta certa — 100 documentos grátis por mês e cêntimos depois, num mercado habituado a mensalidades. A resposta é simples: o nodex não nasceu para ser vendido. É o motor de faturação do Pacioli, o ERP da Glie — construído primeiro para nós, com o rigor de quem vai viver em cima dele. Abri-lo ao teu stack custa-nos pouco, e cada documento emitido cá fora endurece o motor que corre lá dentro. Não precisamos que a faturação legal dê margem; precisamos que seja irrepreensível. Por isso cobramos perto do custo, com tudo incluído. O truque, se quiseres chamar-lhe isso, é este: não há.

Achamos que cumprir a lei não devia ser um custo.