O que é API: contrato entre programas

API (interface de programação de aplicações) é um conjunto de regras, recursos e formatos que permite a um programa solicitar ações ou dados a outro sem conhecer a implementação interna. Ela define o que pode ser pedido, como enviar a solicitação e qual resposta esperar, funcionando como contrato estável entre sistemas distintos.

Você já usou um aplicativo de mapa, pagou com Pix no celular ou pediu um relatório em um painel e o sistema respondeu em segundos. Por trás dessa resposta quase sempre existe uma API conversando com outro serviço, banco ou fornecedor. O leitor leigo sente o efeito, porém raramente vê o contrato que torna a troca possível.

Além disso, quem pesquisa o que é API costuma estar decidindo se vale integrar um sistema, avaliar um fornecedor ou entender um erro técnico que travou o negócio. Por isso este guia explica o mecanismo, os tipos mais comuns, os riscos e os critérios práticos, sem prometer ganho automático de produtividade ou receita.

Para que serve uma API no cotidiano digital?#

Serve para um sistema pedir a outro exatamente o que precisa, de forma repetível e documentável, sem abrir o código-fonte nem a base de dados completa. Segundo o glossário da MDN Web Docs sobre API, a API é um conjunto de recursos e regras dentro de um software que permite interação por programa, e não pela interface humana. Em outras palavras, o navegador, o aplicativo ou o servidor fala com outro componente por meio desse contrato.

No cotidiano, a API aparece quando um e-commerce consulta estoque em um depósito, quando um site embute mapa de terceiros, quando um app de banco valida saldo em outro serviço, ou quando um painel de marketing puxa métricas de uma plataforma. Você não precisa saber qual linguagem o fornecedor usa. Porém precisa entender quais operações estão liberadas, quais dados saem na resposta e quem paga o custo de cada chamada.

Exemplo concreto com números e premissas#

Imagine uma loja online que, a cada pedido confirmado, chama a API do transportador para gerar etiqueta. As premissas desta simulação servem só para raciocinar e não como promessa de mercado. O cenário assume 80 pedidos por dia útil, uma chamada de criação de etiqueta por pedido e uma chamada de consulta de status no dia seguinte. Assim, o volume aproximado fica em 160 chamadas por dia útil. Se o fornecedor limitar 100 chamadas por minuto e 5 mil por dia, a operação cabe no teto diário, no entanto um pico de 300 pedidos em promoção pode estourar a cota e atrasar etiquetas. O benefício da integração automática vem acompanhado do risco de dependência e de cobrança por volume, quando o contrato do fornecedor assim prevê.

Há também o caso em que a API só lê dados. Por exemplo, um sistema interno de crédito consulta o score de crédito de um cliente por meio da interface do bureau. A consulta acelera a análise, porém expõe o negócio a indisponibilidade do parceiro, a mudanças de versão e a obrigações de proteção de dados pessoais quando o retorno inclui informação identificável.

E se a empresa não tiver time de desenvolvimento? Ainda assim ela usa API indiretamente, porque o SaaS que contratou já fala com outros sistemas. A diferença é que o contrato fica escondido na tela. Enquanto isso, o custo de uma falha continua real, com pedido sem etiqueta, login que não valida e relatório vazio.

Na prática, o que eu vejo com mais frequência é time de negócio tratar API como “botão mágico” e só descobrir limites de cota, latência e versão no dia do lançamento. Antes de assinar qualquer integração, eu pediria o inventário de endpoints, o limite de uso, o formato de erro e o responsável por mudanças.

Como funciona uma API na prática?#

Como funciona uma API, em linhas gerais, é um ciclo de pedido e resposta. O cliente monta uma solicitação com destino, operação e eventualmente um corpo de dados. O servidor interpreta o pedido, aplica regras de autenticação e autorização, executa a ação e devolve um status com o resultado. Em APIs na Web, esse diálogo costuma usar HTTP como protocolo de base da troca de recursos na internet.

Pedido, resposta e o papel do contrato#

O contrato da interface de programação de aplicações costuma especificar caminhos, métodos, campos obrigatórios, códigos de status e formatos de erro. Sem isso, cada consumidor inventa um jeito de chamar e a integração vira dívida. A RFC 9205, publicada pelo RFC Editor, trata de boas práticas para construir protocolos e APIs baseadas em HTTP, justamente porque muitas aplicações usam HTTP como substrato além da navegação clássica.

Um pedido típico de leitura pode ser um GET em um endereço que identifica um recurso, por exemplo um pedido número 1042. A resposta bem-sucedida costuma vir com status 200 e um corpo em JSON com os campos combinados. Já a criação de um recurso costuma usar POST, e o servidor pode responder 201 quando o item nasce, conforme a semântica usual de HTTP para recurso criado. O detalhe que mais gera suporte é misturar sucesso HTTP com erro de negócio, ou seja, receber 200 com mensagem de falha escondida no JSON, o que atrasa diagnóstico.

Autenticação entra nesse fluxo. Muitas vezes o cliente envia um token ou uma chave de API no cabeçalho. A chave identifica o aplicativo ou o projeto, porém não substitui autorização fina sobre o que aquele cliente pode ler ou alterar. Se a chave vazar em repositório público, em log ou em aplicativo móvel descompilável, qualquer um pode consumir a cota e acessar o que a chave liberar. Por isso o segredo deve ficar no servidor, com rotação e escopos mínimos.

Custos escondidos do ciclo pedido-resposta#

Cada chamada consome rede, CPU, armazenamento e, em serviços pagos, crédito comercial. Além disso, retries mal configurados multiplicam carga. Um cliente que tenta de novo a cada segundo durante uma queda pode transformar indisponibilidade curta em saturação longa. Por outro lado, ausência de retry deixa o usuário com falha permanente por um erro transitório. O equilíbrio exige timeout, backoff e idempotência nas operações sensíveis, por exemplo cobrança ou emissão de documento.

Se fosse comigo, eu começaria qualquer integração desenhando três caminhos no papel, cobrindo sucesso, erro de validação e indisponibilidade do parceiro. Só depois disso eu ligaria o fio em produção. Quem pula essa etapa quase sempre descobre o comportamento real com cliente esperando na tela.

O que muda entre API REST, API de navegador e API de terceiros?#

API REST é o estilo mais citado em integrações Web modernas. Segundo o guia de práticas de design de Web API da Microsoft Learn, uma implementação RESTful usa HTTP de forma uniforme sobre recursos identificados por URI, com representação tipicamente em JSON ou XML, e busca baixo acoplamento entre cliente e serviço. Isso não significa que todo endpoint chamado de “REST” siga o estilo com rigor. Muitos produtos oferecem HTTP com JSON e documentação própria, o que já resolve o dia a dia, porém não autoriza marketing vazio de “REST puro”.

A API de navegador é outra família. Ela expõe recursos do próprio ambiente do usuário, como geolocalização, mídia ou manipulação do documento. Assim, quando o site pede permissão de localização, a conversa ocorre com o navegador. Quando o mesmo site busca previsão do tempo de um fornecedor, a conversa ocorre pela rede com a API desse fornecedor.

APIs de terceiros trazem velocidade de produto e também dependência. Você ganha mapa, pagamento, envio de e-mail ou modelo de LLM sem construir tudo internamente. No entanto herda limites de uso, mudanças de versão, política de dados e preço do fornecedor. Em produtos de inteligência artificial generativa, a API costuma ser a porta oficial para enviar prompt e receber texto ou embedding. O benefício de velocidade vem com risco de alucinação no conteúdo gerado, de vazamento se alguém colar dado pessoal sem base legal, e de custo variável por token ou por chamada.

Tabela comparativa útil para decisão#

E se o time quiser GraphQL ou outro estilo? Quem prefere GraphQL concentra consultas flexíveis em um esquema, enquanto protocolos binários como gRPC priorizam eficiência entre serviços. Nenhum deles elimina a necessidade de autenticação, autorização, inventário e observação. Trocar o formato sem governança só muda o sotaque do problema.

O erro que mais custa caro aqui é escolher tecnologia por moda e deixar o contrato sem dono. Sem dono, versão antiga fica no ar, documentação some e ninguém sabe qual cliente ainda depende daquele campo. Eu trataria o inventário da API como ativo do produto, não como anexo técnico.

Quais riscos de segurança e de dados uma API concentra?#

Uma API concentra risco porque expõe operações e dados de forma programática, em escala, muitas vezes com autenticação que, se falhar, abre a porta para automação abusiva. A lista OWASP Top 10 de riscos de segurança em API na edição 2023 destaca falhas como autorização quebrada em nível de objeto, autenticação frágil, consumo irrestrito de recursos, configuração insegura e inventário inadequado de endpoints e versões. Esses itens não são receita de ataque. São alertas de defesa para quem projeta, opera ou contrata integração.

O cenário clássico de autorização quebrada ocorre quando o cliente troca o identificador na URL e acessa o pedido de outra pessoa. Se o servidor confia no identificador enviado sem checar se aquele usuário pode ver aquele objeto, o vazamento acontece com uma alteração simples. Por isso toda leitura ou escrita por ID precisa de checagem server-side, nunca só de ocultar o botão na tela.

Consumo irrestrito de recursos aparece quando não há limite de taxa, tamanho de payload ou custo por operação cara. Além do risco de indisponibilidade, há impacto financeiro quando a API dispara e-mail, SMS ou chamada a um modelo pago. Enquanto isso, inventário ruim deixa endpoint de teste ou versão antiga acessível, exatamente o tipo de superfície que a OWASP associa a gestão inadequada.

Quando a API trata dado pessoal, entra a Lei nº 13.709/2018, a LGPD, cujo texto compilado no Planalto dispõe sobre proteção de dados pessoais, inclusive nos meios digitais. Transferir cadastro, documento ou histórico por interface sem base legal, sem minimização e sem controle de acesso não é “detalhe técnico”. É tratamento de dado com deveres do controlador e do operador. O mesmo vale para logs que gravam corpo de resposta completo com CPF ou e-mail.

Diretrizes técnicas de proteção ao longo do ciclo de vida reforçam inventário, autenticação, autorização, validação e telemetria desenhados de propósito, com adoção incremental orientada a risco. A existência de guias setoriais não torna uma empresa automaticamente segura. Porém deixa claro que gateway sozinho, sem regra de autorização por objeto, só centraliza o problema.

Muita gente acha que colocar a API atrás de um gateway resolve sozinho, e quase sempre está enganada, porque gateway sem regra de autorização por objeto e sem inventário só empurra a falha para um ponto único. Eu priorizaria escopos mínimos na chave de API, testes de acesso cruzado entre usuários e alerta de pico de erro 401, 403 e 429 antes de qualquer campanha de crescimento.

Quando vale integrar por API e quando é melhor não?#

Vale integrar por API quando há repetição real de troca de dados, quando o volume justifica automação e quando existe contrato claro de responsabilidade, versão e suporte. Também vale quando o atraso humano gera erro caro, por exemplo digitar pedido duas vezes em sistemas diferentes. Nesses casos, a interface reduz retrabalho, porém introduz custo de construção, monitoramento e resposta a incidente.

Não vale, ou pelo menos não vale ainda, quando o fluxo ocorre poucas vezes por mês, quando o fornecedor não documenta erros, quando a chave precisa ficar no aplicativo do usuário final sem proteção adequada, ou quando o time não consegue operar alerta e rollback. Nestes cenários, uma exportação manual controlada ou um conector maduro de plataforma pode ser menos arriscado do que uma integração caseira frágil. Quem também trabalha com SEO precisa lembrar que automação de publicação via API acelera volume, mas erro de conteúdo ou de URL ainda chega ao leitor e ao rastreador.

Critérios objetivos para a maioria dos times#

1. Frequência. Se a troca acontece várias vezes ao dia, a API tende a pagar o investimento. Se acontece uma vez por trimestre, o custo de manter versão e alerta pode superar o benefício.
2. Criticidade. Se a falha impede venda, login ou entrega, a integração exige plano B e dono nomeado.
3. Sensibilidade do dado. Dado pessoal e segredo comercial pedem base legal, minimização e trilha de auditoria.
4. Maturidade do fornecedor. Documentação versionada, status page e canal de mudança reduzem surpresa. Ausência desses sinais aumenta risco operacional.
5. Observabilidade. Sem correlação de trace_id, métrica de latência e alarme de taxa de erro, você só descobre a quebra pelo reclame do cliente.

E se o fornecedor oferecer só webhook? Webhook é o caminho inverso. O parceiro avisa seu sistema quando algo acontece. Continua sendo interface programática e continua exigindo autenticação, validação de origem e tratamento de reentrega. Trocar o sentido da seta não elimina o contrato.

Depois de acompanhar integrações que nasceram só para o piloto, o padrão que se repete é subestimar operação. Eu só avançaria para produção com limite de taxa conhecido, ambiente de teste, checklist de rotação de chave e um responsável humano por incidente fora do horário comercial quando o fluxo for crítico.

Termos relacionados#

• inteligência artificial generativa Muitos produtos de geração de texto e imagem são consumidos por API, com custo e risco de conteúdo incorreto.
• LLM (modelo de linguagem de grande escala) O acesso programático a modelos costuma ocorrer por endpoints HTTP com autenticação e cotas.
• score de crédito Bureaus e fintechs expõem consultas de score por interfaces que o sistema de análise chama automaticamente.
• CDC (Código de Defesa do Consumidor) Quando a API de um serviço digital falha e prejudica a oferta ao consumidor, entram deveres de informação e de adequada prestação, além da discussão técnica.

Perguntas frequentes sobre API#

As dúvidas abaixo cobrem o que costuma sobrar depois da definição. Elas ajudam quem compara fornecedores, quem precisa explicar o termo para o time de negócio e quem quer saber o que é API sem cair em jargão vazio ou em promessa de resultado fácil.

O que é API em uma frase simples?#

É o contrato que um programa oferece para outro programa pedir dados ou ações de forma previsível. A frase útil para o leigo é que a interface de programação de aplicações é a “tomada” estável, enquanto a implementação interna é a fiação escondida na parede.

Toda API precisa ser API REST?#

Não. API REST descreve um estilo comum em HTTP com recursos e métodos padronizados, porém existem APIs de biblioteca, de navegador, RPC e outros estilos. O que importa para o leitor é a clareza do contrato, a autenticação e o suporte a versão, não o rótulo isolado.

Chave de API e senha de usuário são a mesma coisa?#

Não. A chave de API costuma identificar um aplicativo ou integração, enquanto a senha ou o login identificam uma pessoa. Porém ambas são segredos. Se a chave vazar, o abuso pode consumir cota e acessar dados no escopo liberado, por isso ela não deve ir para o frontend público.

API resolve sozinha a integração entre sistemas?#

Não. A API é necessário meio técnico, porém a integração completa inclui mapeamento de dados, tratamento de erro, monitoramento, acordo de nível de serviço e processo quando o parceiro muda o contrato. Sem isso, a chamada até funciona no teste e falha no pico real.

O que eu olho primeiro na documentação de uma API?#

Eu olharia autenticação, limites de uso, exemplos de erro, política de versionamento e quais campos são obrigatórios. Em seguida, confirmaria se existe ambiente de sandbox e como o fornecedor avisa quebra de compatibilidade. Documentação só com exemplo feliz é sinal de risco operacional.

Usar API de IA aumenta produtividade automaticamente?#

Não há garantia. Ferramentas de IA acessíveis por API podem acelerar rascunhos e classificação, porém exigem revisão humana, controle de custo e cuidado com dado pessoal. Sem esses freios, o time só troca retrabalho de escrita por retrabalho de correção e por fatura variável.

Conclusão#

Para a maioria dos leitores de glossário e de negócio, API deve ser entendida como contrato operacional entre sistemas, e não como atalho mágico de crescimento. Se a troca de dados é frequente, crítica e bem documentada, integrar por interface costuma reduzir erro manual. Se o volume é baixo, o segredo não tem onde morar com segurança ou o fornecedor não versiona com clareza, adiar a integração é decisão madura.

A resposta muda quando entra dado pessoal, pagamento ou operação que não pode falhar em silêncio. Nesses casos, inventário, autorização por objeto, limite de taxa e plano B pesam mais do que a elegância do endpoint. O primeiro passo prático é listar quais sistemas já conversam hoje, quem paga cada chamada e qual falha do último trimestre nasceu de contrato mal entendido.

Em seguida, peça a documentação, teste o caminho de erro e só então automatize o caminho feliz. Assim você usa a API como ferramenta de precisão, com olhos abertos para custo, dependência e responsabilidade.

Este texto sobre API (interface de programação de aplicações) é informativo e geral. Não constitui consultoria jurídica, de segurança ofensiva nem orientação individual sobre conformidade com a LGPD ou escolha de fornecedor. Decisões que envolvam dado pessoal, autenticação e integração crítica dependem do contexto de cada organização e devem ser avaliadas com profissionais habilitados e com a documentação oficial vigente na data do projeto.