Entre março e maio de 2026, entrevistamos doze equipes de plataforma em fintechs brasileiras — instituições com carteira digital, crédito digital e infraestrutura de pagamentos — para entender como escolhem e mantêm padrões de API externa e interna. O objetivo não era declarar um vencedor, mas mapear critérios reais de decisão em ambientes regulados, onde cada endpoint pode ser objeto de auditoria e onde latência percebida impacta conversão de usuários finais.
Contexto regulatório e de mercado
No Brasil, fintechs que operam sob regulação do Banco Central enfrentam exigências de rastreabilidade, registro de transações e segregação de ambientes que influenciam diretamente o design de APIs. Endpoints expostos a parceiros (Open Finance, integrações B2B) precisam de versionamento explícito e documentação auditável. APIs internas, por outro lado, servem dezenas de squads com ritmos de deploy independentes — pressionando por flexibilidade de schema e redução de over-fetching.
Essa dualidade — rigidez externa, agilidade interna — apareceu em onze das doze organizações consultadas como fator determinante na escolha de paradigma por camada de exposição.
REST na camada externa
REST permanece dominante em APIs públicas e de parceiros. Motivos citados incluem: maturidade de ferramentas de gateway, suporte nativo a cache HTTP, alinhamento com especificações Open Finance e facilidade de auditoria por endpoint. Equipes relataram que revisores regulatórios e auditores externos compreendem contratos REST/OpenAPI com menor fricção do que schemas GraphQL dinâmicos.
Entretanto, REST não escapa de problemas de versionamento. Três organizações mantêm três ou mais versões simultâneas de endpoints críticos, com janelas de depreciação que chegam a dezoito meses — período considerado necessário para migrar parceiros legados sem interrupção de serviço.
GraphQL na camada interna
GraphQL concentrou adoção em BFFs (Backend for Frontend) e agregadores internos. Squads de produto mobile e web citaram redução de round-trips e autonomia na composição de queries como ganhos mensuráveis. Uma fintech de crédito digital reportou redução de 40% no número de chamadas de rede em telas de onboarding após migração de dez endpoints REST para um gateway GraphQL federado.
Os custos também são documentados: complexidade de resolvers, risco de queries N+1 mal otimizadas e necessidade de ferramentas de análise de profundidade e complexidade de query. Duas equipes revertiram parcialmente para REST após incidentes de degradação causados por queries ad hoc sem limites de profundidade.
Comparativo de critérios
Organizamos os critérios mais citados em cinco dimensões: governança, performance, experiência do desenvolvedor, operação e conformidade. REST pontua melhor em governança externa e cache; GraphQL em flexibilidade de consumo e redução de acoplamento entre frontends e múltiplos microsserviços.
- Governança: REST favorece contratos explícitos por recurso; GraphQL exige disciplina de schema registry e políticas de evolução.
- Performance: REST beneficia-se de CDN e cache intermediário; GraphQL demanda DataLoader e batching conscientes.
- DX interna: GraphQL reduz coordenação entre squads de frontend e backend em produtos com UI complexa.
- Operação: REST simplifica observabilidade por endpoint; GraphQL requer instrumentação adicional por operação.
- Conformidade: REST alinha-se melhor a auditorias de exposição de dados pessoais por endpoint.
Padrão híbrido emergente
Oito das doze organizações adotaram arquitetura híbrida: REST (frequentemente OpenAPI 3.x) na borda, GraphQL ou gRPC internamente. Essa separação por camada de confiança reflete princípios de zero trust aplicados a contratos de API — o que é exposto ao exterior passa por gatekeeping rigoroso; o que circula dentro do perímetro de confiança pode ser mais flexível.
Recomendamos que equipes documentem explicitamente a fronteira entre camadas e evitem expor schemas GraphQL diretamente à internet sem gateway de políticas. A experiência das fintechs consultadas sugere que o custo de retrocompatibilidade em APIs públicas supera, na maioria dos casos, os benefícios de flexibilidade de query para consumidores externos.
Conclusão
A pergunta "REST ou GraphQL?" mal formulada obscurece uma decisão mais útil: qual paradigma para qual camada de exposição, sob quais restrições regulatórias e com qual maturidade operacional. Fintechs brasileiras que prosperam nesse equilíbrio tratam APIs como produtos com ciclo de vida, não como detalhe de implementação — e escolhem ferramentas que sustentam essa disciplina, independentemente da moda do momento.