🔗 Testador de Webhooks IFTTT ☆

Teste webhooks do IFTTT sem sair do navegador

Testador de Webhooks IFTTT Grátis envia uma requisição POST direto para maker.ifttt.com com o nome do evento, sua chave e até três valores JSON, exatamente como seu applet espera. Ideal para depurar automações, conferir chaves e confirmar que o serviço recebe o payload.

Como testar um applet

• Crie um applet de Webhooks no IFTTT e copie a chave na página do serviço
• Digite o nome do evento e a chave acima
• Adicione value1, value3 se o applet usar e envie

Bom saber

• A requisição vai direto do navegador para o IFTTT, sem proxy
• Um teste bem-sucedido só significa que o IFTTT aceitou o gatilho; veja o log do applet
• Sua chave nunca é armazenada ou registrada

Como funciona o teste de webhook

Webhooks do IFTTT são endpoints HTTPS simples: a chave fica no caminho e um corpo JSON opcional carrega até três valores. O testador envia uma requisição real do navegador (sujeita a CORS, a resposta pode ser opaca) e reporta o status HTTP, o tempo e a resposta legível quando permitido. Um 200 confirma chave e nome do evento; 401 e 404 apontam chave ou evento errados. O teste não prova que a ação do applet rodou.

Formatos, limites e parâmetros

Privacidade: nada passa pelo 0Appz

Uma chave IFTTT pode disparar automações reais; enviá-la a um testador de terceiros é risco concreto. Aqui a requisição sai do navegador direto para o IFTTT: a chave é digitada na página, usada localmente e nunca transmitida a nós nem armazenada.

Checklist de depuração de webhooks

• Verifique se o nome do evento corresponde exatamente, é case-sensitive.
• Recopie a chave da página Webhooks; espaços a quebram.
• Confirme que o applet está conectado e ligado.
• CORS pode esconder a resposta mesmo com sucesso: use o log de atividade.
• Rotacione a chave se ela já foi colada em ferramenta não confiável.

Veja também as ferramentas de desenvolvimento para cabeçalhos, webhooks e depuração de API.

Webhooks, payloads e códigos de resposta

Um webhook é apenas uma requisição HTTP que um serviço faz a uma URL que você controla, e testá-lo significa reproduzir essa requisição fielmente. O método é quase sempre POST e o corpo geralmente é JSON, então o cabeçalho Content-Type deve dizer application/json ou a automação receptora pode rejeitar o payload. O serviço Webhooks do IFTTT é um caso especial: aceita três valores chamados value1, value2 e value3, que podem ser enviados como corpo JSON ou como campos de formulário codificados na URL. Ficar dentro desses três campos é a principal restrição de design, então empacote dados estruturados em uma única string JSON em value1 quando precisar de mais. Códigos de resposta dizem o que aconteceu: 200 significa que o serviço aceitou o evento, 400 geralmente indica JSON malformado ou campo ausente, 401 ou 403 que a chave está errada ou revogada, e 404 que o nome do evento não existe. Um 500 é problema do serviço, não seu, e repetir a mesma requisição é razoável. Duas notas operacionais: muitos serviços deduplicam payloads idênticos, então um teste que envia o mesmo corpo duas vezes pode disparar só uma, e intermediários de rede podem cachear ou bloquear requisições sem os cabeçalhos certos. Ao testar, verifique também o corpo da resposta além do código de status, porque algumas APIs retornam 200 com um objeto de erro dentro.