A maior parte dos cartões corporativos brasileiros tem "API" no marketing e dois endpoints reais: listar transações e bloquear cartão. O resto continua sendo painel web ou ligação para o gerente. Esse post é sobre por que Full API — todo verbo do cartão como HTTP — não é nice-to-have; é o requisito mínimo de gestão de despesas em 2026.
O que "Full API" significa
Full API quer dizer: tudo o que o painel faz, a API REST faz. Sem exceção. Sem "essa operação requer aprovação manual no telefone". Sem "pra isso fale com a sua gerente de conta". A lista mínima:
| Operação | Endpoint | Resposta esperada |
|---|---|---|
| Emitir cartão | POST /v2/cards | 200 com PAN, ID e status |
| Listar cartões | GET /v2/cards | 200 com paginação por cursor |
| Detalhar cartão | GET /v2/cards/:id | 200 com saldo, transações, metadata |
| Atualizar limite | PATCH /v2/cards/:id | 200 com novo estado |
| Pausar cartão | PATCH /v2/cards/:id { status: "paused" } | 200 imediato |
| Retomar cartão | PATCH /v2/cards/:id { status: "active" } | 200 imediato |
| Cancelar | DELETE /v2/cards/:id | 200 final |
| Listar transações | GET /v2/transactions | 200 com filtros |
| Webhooks de eventos | (push) | schema tipado, idempotency_key |
| Disputas/chargebacks | POST /v2/disputes | 200 com ticket ID |
| Tokenização wallet | POST /v2/cards/:id/wallet_tokens | 200 com token |
Se o seu cartão "tem API" mas qualquer uma dessas operações exige call center, não tem Full API. Tem API parcial — que é pior, porque sugere automação possível e não entrega.
A diferença prática
Cartão com API parcial (a maioria do mercado)
Cenário: você descobre 23h de quarta que um fornecedor está cobrando 3x o valor combinado. Você quer pausar só esse fornecedor e investigar amanhã.
- Liga no SAC. Robô. 22 minutos.
- Pessoa atende, pede confirmação por SMS no celular que está com outra pessoa.
- "Para pausar, vamos precisar cancelar o cartão inteiro."
- Você decide aguentar até de manhã.
- Amanhã: 30 minutos de processo formal, 11 fornecedores afetados.
Cartão com Full API (HubCard)
curl -X PATCH https://api.hubcard.one/v2/cards/card_01HX7P3M9 \
-H "Authorization: Bearer sk_live_••••" \
-d '{"status": "paused"}'
# 140ms depois
{ "id": "card_01HX7P3M9", "status": "paused", "paused_at": "2026-05-16T23:14:08Z" }
Você volta a dormir. Os outros 30 fornecedores continuam rodando. De manhã, investiga com calma e ou cancela ou retoma.
A diferença não é tempo. É autonomia operacional. Detalhamos isso em por que cancelar um cartão corporativo deveria ser um POST.
O que Full API destrava
1. Orquestração por agentes
Agentes de IA só podem mover dinheiro de forma segura se tiverem endpoints programáticos com limite, escopo e cancelamento. Sem Full API, você confia no agente; com Full API, você confia no escopo. Veja dê um cartão para seu robô e como usar o MCP do HubCard.
2. Fechamento contábil em tempo real
Webhook tipado dispara em milissegundos. Seu ERP recebe tx.captured antes mesmo de a transação aparecer no painel. Conciliação contábil deixa de ser exercício mensal e vira processo contínuo. Detalhes em webhooks tipados na API de cartões.
3. Auditoria como query
Sem Full API, auditoria é Excel cruzando PDF. Com Full API, auditoria é SQL no warehouse. Três queries de 15 minutos toda sexta detectam SaaS órfão, anomalia de teto e vendor lock-in. Playbook em auditoria de fornecedores em 15 minutos.
4. Cartão por job, por agente, por experimento
Quando emitir é um POST e cancelar é um DELETE, o custo marginal de criar cartão extra é zero. Isso destrava padrões impossíveis com cartão master:
- Cartão por job de fine-tune: limite = orçamento + 10%, expira ao final.
- Cartão por campanha de growth: cada campanha tem seu próprio cartão, auditoria isolada.
- Cartão por experimento de dev: dev testa nova API sem medo de "estourar o cartão da empresa".
5. Self-service real
Quando engenharia consegue emitir e cancelar cartão sem fila, o time financeiro deixa de ser polícia. O CFO opera por exceção, não por aprovação. Em casos como o da Plúria, o tempo do CFO em "aprovação de cartão" caiu de 6h/semana para zero.
O que não é Full API
Lista do que não conta:
- ❌ Endpoint que retorna PDF da fatura.
- ❌ "API" que envia email pro suporte.
- ❌ Webhook não tipado, JSON livre, sem schema versionado.
- ❌ Endpoint que existe mas tem rate limit hostil (3 calls/minuto).
- ❌ Documentação "sob NDA".
- ❌ "Tem API mas precisa habilitar com nosso time comercial."
Se você se identificou com qualquer um desses, você não tem cartão com Full API. Tem cartão com fachada de API.
Os argumentos contra Full API (e por que estão errados)
"Risco de fraude é maior se tudo é API"
Falso. Cartão com Full API tem Idempotency-Key, rate limit, audit log e webhooks de anomalia. Cartão sem API tem PDF mensal e ligação. Qual é mais fraudável?
"A maioria das empresas não precisa de API"
Talvez não em 2020. Em 2026, qualquer empresa com 20+ fornecedores recorrentes precisa. E em 2027, qualquer empresa que opera agentes em produção precisa por sobrevivência.
"API é coisa de empresa grande"
Inverso. Empresa pequena precisa mais de API — porque não tem time para operar processo manual. Os clientes mais ativos da nossa API são startups de 5–20 pessoas com 40+ fornecedores cada.
"Vamos lançar API ano que vem"
Quem está prometendo Full API "no roadmap" tipicamente está há 3 anos prometendo. Não é prioridade comercial deles. Não vai sair.
O teste do café
A forma rápida de descobrir se o seu fornecedor de cartão tem Full API real:
"Posso emitir um cartão, ajustar limite, pausar, retomar e cancelar — tudo via API, sem qualquer aprovação manual, em menos de 60 segundos por operação?"
Se a resposta tiver "sim, mas", a resposta é "não".
Como o HubCard se posiciona
A gente nasceu Full API. 4 verbos REST cobrem 100% do ciclo de vida do cartão. Webhooks tipados entregam todo evento com schema versionado. Idempotência obrigatória garante que retry é seguro. MCP server expõe tudo isso pra agentes Claude/GPT. SDKs em 4 linguagens (TypeScript, Python, Go, Ruby) com tipos garantidos. Documentação OpenAPI publicada, versionada e válida — não PDF.
Não é diferencial, é o desenho. Se você está avaliando provedor de cartões corporativos ou API de cartões pré-pago, Full API tem que ser linha de base — não checkbox.
E se você ainda está operando com cartão sem Full API hoje, o playbook de migração em 60 dias cobre como sair.
Cartão sem API é planilha. Cartão com Full API é infraestrutura. Escolha o que você quer integrar no seu stack.