Isto sai do teu navegador. Vai para api.github.com. Envía la petición que has escrito al servidor que has puesto en la URL.
Uma bancada de trabalho para APIs HTTP que corre inteiramente no teu navegador: sem servidor, sem conta, sem extensão. Faz quatro coisas: envia pedidos e explica-te porque falham, converte coleções entre Postman, Bruno, Insomnia, OpenAPI, HAR e curl, gera código em onze linguagens, e compara duas versões de uma API para te dizer o que quebra.
O que NÃO é: um substituto do Postman ou do Bruno. Uma página web não pode chamar localhost nem qualquer API que não publique cabeçalhos CORS — isso não é uma limitação desta ferramenta, é como funcionam os navegadores. Para a tua API local, um cliente de ambiente de trabalho. Aqui, em contrapartida, tens o que eles não te podem dar: saber o que o navegador fez de facto.
Quando um pedido a outro domínio falha, o navegador diz apenas TypeError: Failed to fetch e mais nada. Com essa mensagem não se distingue «o meu servidor está em baixo» de «o meu servidor respondeu e o navegador escondeu-me a resposta» — dois problemas com soluções opostas.
Esta ferramenta separa-os: ao falhar, lança um segundo pedido opaco para o mesmo endereço. Esse o navegador envia mesmo, e não o rejeita por causa do CORS. Se se completar, o teu servidor respondeu e o que falta são cabeçalhos. Se também falhar, não se chegou ao servidor e o CORS não tem nada a ver com isso.
O Postman e o Bruno não conseguem fazer isto: são programas de ambiente de trabalho e o CORS não se lhes aplica.
Com métodos como PUT, PATCH ou DELETE, com um Content-Type que não seja de formulário, ou com qualquer cabeçalho próprio, o navegador envia primeiro um pedido OPTIONS a pedir permissão. Se o teu servidor não lhe responder, o pedido real nunca chega a sair mesmo que a tua API funcione na perfeição.
A ferramenta diz-te isso antes de enviares e assinala-te qual das três coisas o provoca, porque a solução é diferente em cada caso.
O navegador só deixa ler sete cabeçalhos (content-type, cache-control…). Os restantes estão lá —vês no separador Rede— mas o JavaScript não lhes pode tocar, a não ser que o servidor os publique com Access-Control-Expose-Headers.
Se te falta o teu X-RateLimit-Remaining, não é uma falha: é isto. A ferramenta avisa-te quando só chegam os sete.
O mesmo ao enviar: há cabeçalhos que o navegador não deixa definir (Host, Origin, Cookie, User-Agent…). São descartados e diz-se-te quais, em vez de fingir que foram enviados.
Cola ou arrasta um export do Postman, do Insomnia, um HAR do navegador, uma especificação OpenAPI (JSON ou YAML), um ficheiro .bru do Bruno ou um punhado de comandos curl: o formato reconhece-se sozinho. Sai como coleção do Bruno (um .zip com a sua árvore de pastas), como coleção do Postman ou como comandos curl.
Porquê aqui e não num conversor web qualquer: uma coleção exportada traz os teus tokens lá dentro. É exatamente o ficheiro que não devias carregar para um servidor alheio para o converteres. Aqui nunca sai do navegador — e a ferramenta enumera-te as credenciais que encontra, mascaradas, para saberes o que estás prestes a partilhar.
Os scripts do Postman (pm.test, pm.environment) e os do Bruno são código contra um ambiente que aqui não existe: não se traduzem. Os campos de ficheiro guardam o caminho do disco de quem exportou, não o conteúdo. As templates do Insomnia só têm valor dentro do Insomnia.
Tudo isso aparece como aviso ao importar. Uma migração que engole os scripts sem o mencionar é das que só descobres em produção.
O pedido que tiveres montado, pronto a colar em onze destinos: cURL, fetch, axios, Python (requests), HTTPie, Go, Java, C#, PHP, PowerShell e Rust.
Não são exemplos ilustrativos: vêm com os seus import, com os escapes de cada linguagem —um apóstrofo no corpo não te parte o comando— e com os detalhes que se fazem mal por hábito (em C# o Content-Type vai no conteúdo e não nos cabeçalhos; em Go um import sem uso não compila).
Cola duas especificações OpenAPI e diz-te o que mudou e quais dessas mudanças quebram um cliente que já existe. Essa é a pergunta a sério antes de publicares, e é o que um diff a cores não responde.
Pares que parecem iguais num diff e significam o contrário: acrescentar um parâmetro opcional não quebra nada, acrescentá-lo obrigatório sim; acrescentar um valor a uma lista não quebra, retirá-lo sim; retirar um parâmetro de query é ignorado, retirar um de rota muda o URL.
Cada resultado diz porquê, não só o quê: um veredito sem o porquê obriga-te a acreditar, e com ele dá para discutir. O relatório sai em Markdown para colares num pull request.
Converter, gerar código e comparar especificações não enviam nada para lado nenhum: acontecem por inteiro dentro do teu navegador.
Enviar um pedido, esse sai, evidentemente: vai para o servidor que escreveres, com os teus cabeçalhos e o teu corpo. Da primeira vez mostra-se-te exatamente o que vai ser enviado —método, endereço, cada cabeçalho e o corpo— com as credenciais tapadas mas contadas. Depois, o aviso ao lado do botão continua a dizer-te a que máquina vai cada envio.
E para conseguir diagnosticar uma falha, envia-se um segundo pedido para esse mesmo endereço, sem cabeçalhos e sem ler a resposta, só para saber se o servidor está vivo.
Isto sai do teu navegador. Vai para api.github.com. Envía la petición que has escrito al servidor que has puesto en la URL.