O que é uma API e como dois sistemas conversam entre si?

APIs aparecem em quase todo sistema moderno: quando um aplicativo consulta um frete, confirma um pagamento, busca um endereço, envia uma mensagem ou pede dados a outro serviço, existe uma boa chance de uma API estar no meio.

A sigla vem de Application Programming Interface — interface de programação de aplicações. O nome parece técnico, mas a ideia central é simples: uma API define como um software pode pedir algo a outro software e o que deve esperar de volta.

Resposta rápida

Uma API funciona como um contrato entre sistemas. Ela diz quais operações estão disponíveis, quais dados precisam ser enviados, como a solicitação deve ser feita e qual formato de resposta será devolvido.

Em uma API web, a conversa normalmente segue este caminho:

1. um sistema envia uma requisição;
2. a requisição informa o recurso desejado e a ação;
3. o servidor verifica os dados e as credenciais;
4. o servidor executa a operação;
5. uma resposta volta com um resultado ou um erro.

Isso permite que dois sistemas sejam desenvolvidos por empresas, equipes ou linguagens diferentes e ainda consigam conversar.

API não é necessariamente internet

Quando falamos em API hoje, é comum imaginar uma URL recebendo JSON pela internet. Esse é um tipo muito importante de API, mas o conceito é mais amplo.

Uma biblioteca de programação também pode oferecer uma API. O próprio navegador disponibiliza APIs para câmera, localização, áudio, armazenamento e várias outras funções.

O MDN define API como um conjunto de recursos e regras que permite que um software interaja com outro software ou componente. Em outras palavras, a API é a interface programável dessa interação.

Um exemplo prático: consultar um pedido

Imagine uma loja virtual que precisa perguntar ao sistema de pedidos qual é a situação do pedido 123.

Uma API poderia disponibilizar um endereço como:

GET https://api.exemplo.com/pedidos/123

A parte /pedidos/123 identifica o recurso. O método GET informa a intenção: queremos obter dados.

O servidor poderia responder:

{
  "id": 123,
  "status": "enviado",
  "transportadora": "Exemplo Log",
  "codigo_rastreio": "ABC123"
}

A loja não precisa saber como o outro sistema guarda o pedido internamente. Pode ser PostgreSQL, MySQL, arquivos ou outra tecnologia. Ela precisa conhecer apenas o contrato da API.

Essa separação é uma das razões pelas quais APIs são tão úteis: cada sistema pode mudar internamente sem obrigar todos os outros a conhecerem seus detalhes.

O que existe dentro de uma requisição

Em APIs web baseadas em HTTP, algumas peças aparecem com frequência.

Endpoint

É o endereço usado para acessar determinado recurso ou operação.

Exemplo:

https://api.exemplo.com/clientes/42

Método HTTP

O método ajuda a indicar o que a requisição pretende fazer.

Alguns dos mais conhecidos são:

• GET: obter uma representação de um recurso;
• POST: enviar dados para processamento, frequentemente criando algo;
• PUT: substituir a representação de um recurso;
• DELETE: solicitar a remoção de um recurso.

Esses significados são definidos pela semântica do HTTP; a API escolhe como organizar seus recursos dentro dessas regras.

Cabeçalhos

Os headers carregam informações adicionais, como o tipo de conteúdo aceito, versão, idioma ou credenciais de autenticação.

Um exemplo comum é:

Authorization: Bearer SEU_TOKEN

O token não é a informação que queremos consultar. Ele serve para provar que o cliente tem permissão para fazer aquela chamada.

Corpo da requisição

Algumas operações precisam enviar dados.

Por exemplo:

{
  "nome": "Ana",
  "email": "ana@exemplo.com"
}

JSON é muito comum em APIs web, mas não é obrigatório. APIs podem usar outros formatos dependendo da necessidade.

E como o outro sistema responde?

A resposta normalmente contém duas coisas importantes:

1. um código de status;
2. os dados da resposta, quando existirem.

No HTTP, os códigos são agrupados por classes. Respostas 2xx indicam sucesso; 4xx normalmente apontam um problema relacionado à solicitação do cliente; 5xx indicam que o servidor não conseguiu cumprir uma solicitação aparentemente válida.

Alguns exemplos conhecidos:

• 200 OK: a operação foi bem-sucedida;
• 201 Created: um recurso foi criado;
• 400 Bad Request: a requisição está inválida;
• 401 Unauthorized: faltam credenciais válidas;
• 404 Not Found: o recurso não foi encontrado;
• 500 Internal Server Error: houve uma falha no servidor.

Um sistema bem construído não olha apenas para os dados. Ele também precisa saber lidar com falhas, tentativas novamente, tempo limite e respostas inesperadas.

Como dois sistemas sabem exatamente o que enviar?

É aqui que entra a documentação.

Uma API precisa informar quais endpoints existem, quais parâmetros são obrigatórios, quais formatos aceita, como funciona a autenticação e quais respostas podem voltar.

O padrão OpenAPI, por exemplo, permite descrever APIs HTTP de forma estruturada e independente da linguagem de programação. Ferramentas podem usar essa descrição para gerar documentação, clientes, testes e outras integrações.

É por isso que uma integração não deveria depender de “adivinhar” como um serviço funciona.

API, HTTP e REST são a mesma coisa?

Não.

API é o conceito de interface programável.

HTTP é um protocolo de comunicação amplamente usado na web e em APIs.

REST é um estilo arquitetural associado a determinadas formas de organizar interações entre cliente e servidor.

Por isso, dizer “API” não significa automaticamente “REST”. Existem APIs que usam HTTP sem seguir estritamente REST e APIs que usam outros mecanismos de comunicação.

Como a autenticação entra nessa conversa?

Nem toda API é pública.

Um serviço pode exigir uma chave de API, um token, OAuth ou outro mecanismo para identificar e autorizar quem está fazendo a chamada.

A regra prática é importante: credenciais de API devem ser tratadas como segredo. Elas não devem ser colocadas deliberadamente em páginas públicas, repositórios abertos ou código entregue ao navegador quando isso permitir acesso privilegiado.

Chaves de API e arquivos .env fazem parte desse mesmo assunto: como guardar segredos de integração sem expô-los no código ou em repositórios públicos.

E onde a inteligência artificial entra nisso?

Um modelo de linguagem, sozinho, gera e interpreta texto. Para consultar um banco, enviar uma mensagem, criar um registro ou executar uma ação em outro sistema, ele precisa receber acesso a alguma ferramenta.

Essa ferramenta frequentemente chama uma API por trás.

API e MCP aparecem juntos com frequência em sistemas de inteligência artificial, mas não são sinônimos: uma API define uma interface programável entre sistemas, enquanto o MCP trata de uma forma padronizada de expor contexto e ferramentas para modelos e agentes.

Uma API elimina a necessidade de conhecer o outro sistema?

Ela reduz muito esse acoplamento, mas não elimina a necessidade de regras claras.

Quem integra ainda precisa conhecer:

• o contrato da API;
• a autenticação;
• os limites de uso;
• os formatos de dados;
• os possíveis erros;
• a política de versionamento.

Se uma API muda sem compatibilidade, integrações podem quebrar. Por isso documentação, versionamento e testes são parte importante do trabalho.

Em resumo

Quando dois sistemas “conversam”, não existe mágica. Existe uma interface definida.

Um lado envia uma solicitação seguindo regras conhecidas. O outro processa essa solicitação e devolve uma resposta também dentro de regras conhecidas.

Uma API é justamente a camada que torna essa conversa previsível.

Ela não exige que os sistemas tenham sido feitos pela mesma empresa, na mesma linguagem ou com o mesmo banco de dados. Eles precisam apenas concordar sobre como pedir, como responder e como tratar erros e permissões.

É por isso que APIs estão por trás de tantas integrações que usamos todos os dias — e por que entendê-las ajuda a compreender webhooks, automações, agentes de IA e MCP.

Veja também outras explicações em Tecnologia & IA.