Documentação do AnyHook

O AnyHook não precisa de SDK nem de pacote: você troca a URL do webhook no painel do remetente, e seu handler continua recebendo as mesmas requisições. Um ponto para planejar: novas tentativas e replays levam o timestamp original do remetente, então, onde a assinatura do remetente expira (Stripe, Slack e os demais com janela de tolerância em /providers), verifique o cabeçalho AnyHook-Signature para aceitá-los.

Caminho mais rápido (sem conta): rode curl -X POST https://anyhook.net/api/v1/quickstart para receber na hora uma URL de entrada ativa e uma chave de API, ideal para agentes de IA e testes rápidos. O endpoint expira em 7 dias se você não o vincular à sua conta pela claim_url devolvida. Aponte seu remetente para a inbound_url devolvida e leia os eventos com GET /api/v1/events e GET /api/v1/events/{id}; o campo next_steps da resposta traz cada comando.

1. 1
   Crie uma conta

   Acesse anyhook.net/sign-up e crie uma conta gratuita. Sem cartão de crédito.
2. 2
   Crie um app

   Um app representa uma origem de webhooks. Uma conta nova abre direto no formulário: dê um nome ao app (por exemplo, "Stripe Production") e, se quiser, a URL do seu servidor, para onde o AnyHook encaminha cada evento depois de recebê-lo. Deixe em branco e o app registra tudo no log, sem encaminhar. Adicione destinos quando quiser, até 3 por app no Free.
3. 3
   Aponte seu remetente para o AnyHook

   A página do app mostra sua URL de entrada e onde cada remetente comum pede por ela (por exemplo, Stripe → Developers → Webhooks). Cole a URL lá, no lugar da URL antiga do webhook:

   https://in.anyhook.net/{user-slug}/{app-slug}

   A página fica observando: a primeira requisição aparece nela em segundos. Ainda não tem de onde enviar? Clique em Send a test event na mesma página.

Cada app ganha uma URL de entrada única:

https://in.anyhook.net/{user-slug}/{app-slug}

• user-slug: o identificador da sua conta, visível nas configurações do painel.
• app-slug: único por app, gerado a partir do nome do app, mas editável.

O endpoint de entrada aceita qualquer requisição POST e também responde aos handshakes de validação da configuração: um GET com hub.mode=subscribe (a verificação hub.challenge da Meta) recebe o desafio de volta automaticamente, mesmo antes de o app ser configurado. Qualquer outro método recebe 405. Páginas web e formulários HTML simples também podem enviar para ele (veja Handlers de código). O AnyHook responde HTTP 200 assim que o evento está gravado na fila durável, em cerca de um segundo, seja qual for a velocidade do seu endpoint de destino, então o remetente nunca espera por ele.

O AnyHook detecta o remetente automaticamente pelos cabeçalhos recebidos e verifica a assinatura do payload na edge (o Cloudflare Worker em in.anyhook.net). Para ativar a verificação, selecione seu provedor de webhooks ao criar um app e cole o segredo de assinatura do webhook do provedor (por exemplo, o whsec_... da Stripe).

A edge rejeita as requisições que falham na verificação, e elas nunca chegam ao seu endpoint. A página do app conta essas requisições, e as 5 primeiras de cada dia ficam guardadas no log de eventos como rejected, com cabeçalhos e corpo, para você ver o motivo.

O AnyHook usa uma arquitetura assíncrona, baseada em fila, para desacoplar o remetente dos webhooks do seu backend:

1. Recebimento na edge: o Cloudflare Workers aceita o POST, verifica a assinatura e responde 200 assim que o evento está armazenado de forma durável, em cerca de um segundo.
2. Fila: a edge publica o evento em uma fila de mensagens durável (Upstash QStash). A conexão HTTP do remetente já está fechada.
3. Encaminhamento: o QStash entrega o evento ao forwarder do AnyHook, que faz um POST do payload original para o seu endpoint de destino.
4. Log: o AnyHook registra cada etapa, com cabeçalhos/corpo de entrada, status da entrega, código e corpo da resposta do seu endpoint e latência.

O contrato, dito com todas as letras, porque um relay vago sobre as próprias garantias empurra essa imprecisão para o seu código:

1. Pelo menos uma vez (at-least-once), não exatamente uma vez. As novas tentativas são o produto, e uma nova tentativa depois de uma resposta perdida não se distingue de uma entrega nova. De vez em quando, você vai receber o mesmo evento duas vezes; nenhum relay pode prometer o contrário, e os que prometem estão descrevendo o caminho feliz. Seu handler precisa ser idempotente, e o id do evento que encaminhamos em X-AnyHook-Delivery é a chave para deduplicar.
2. Sem garantia de ordem. Com novas tentativas e entregas simultâneas, um evento posterior pode chegar antes de um anterior que o AnyHook ainda está tentando de novo. A maioria dos remetentes também não promete ordem antes de os eventos chegarem até nós. Ordene por um campo dentro do payload (uma versão, um updated_at), nunca pela hora de chegada.
3. Não deduplique pela assinatura. O cabeçalho AnyHook-Signature é assinado de novo com um timestamp novo a cada tentativa, de propósito, para que as novas tentativas nunca falhem na sua janela de tolerância. Duas entregas do mesmo evento levam assinaturas diferentes; o que fica constante é o id do evento.
4. Aceito significa durável. A edge só responde 200 depois que o evento está gravado, e, atrás da fila, há dois armazenamentos de fallback antes que a edge chegue a responder 503. Um 503 da URL de entrada significa que nada foi armazenado, e a nova tentativa do próprio remetente é a rede de segurança; é por isso que respondemos 503 em vez de fingir.

Quando seu destino responde com um erro temporário ou dá timeout, o AnyHook tenta de novo automaticamente, com backoff exponencial:

Quais respostas disparam novas tentativas?

Nem todo erro é temporário. O AnyHook classifica a resposta do seu endpoint para não gastar tentativas, nem a sua franquia de computação, com erros que tentar de novo não resolve:

Cada tentativa fica registrada com o corpo completo da resposta e o código de status. Tanto as falhas definitivas 4xx quanto as temporárias contam para o circuit breaker: 20 falhas consecutivas de qualquer tipo abrem o circuit breaker.

Notificações de falha

O AnyHook envia alertas por e-mail em limiares específicos, e não a cada evento, para que sua caixa de entrada continue gerenciável:

• 1ª falha: alerta imediato com o código de status e o destino.
• 5ª falha consecutiva: alerta de escalonamento com sugestões.
• 20ª falha consecutiva: o circuit breaker abre (veja abaixo) e o alerta do circuit breaker é enviado.

Um e-mail em cada limite acima, depois um em cada etapa do circuit breaker (cada pausa e a desativação), nunca um por evento. Uma única entrega bem-sucedida zera o contador.

Se o AnyHook detectar 20 falhas de entrega consecutivas para o mesmo destino (incluindo 4xx definitivos), o circuit breaker abre e começa um escalonamento progressivo:

Como funciona

• A entrada continua recebendo. Sua URL de entrada fica ativa o tempo todo: os eventos da Stripe, do GitHub etc. continuam sendo aceitos e armazenados. Só a entrega de saída para o seu destino fica pausada.
• Quando cada pausa termina, o AnyHook faz um teste half-open: o próximo evento testa seu destino. Se der certo, o circuito fecha e tudo é zerado.
• Um único sucesso zera tudo: a contagem de falhas consecutivas e a de aberturas voltam a zero.
• Os eventos recebidos durante uma pausa ficam armazenados com status circuit_open e ficam disponíveis para replay assim que seu destino se recuperar.
• Você recebe uma notificação por e-mail a cada etapa do escalonamento, com a URL do destino, a contagem de falhas e a duração da pausa.
• Se o destino for desativado (abertura 5), você precisa reativá-lo manualmente pelo painel.

Essa abordagem progressiva dá tempo para seu servidor se recuperar e poupa sua franquia de computação das novas tentativas que um endpoint fora do ar consumiria.

Todo evento que chega à sua URL de entrada fica registrado, aconteça o que acontecer com a entrega. O log começa quando você aponta o provedor para o AnyHook: um evento que falhou antes disso só existe no provedor (para a Stripe, veja como fazer o replay de um webhook). Cada entrada do log inclui:

• Cabeçalhos e corpo de entrada completos (como o remetente enviou)
• Status da entrega: queued → success / retrying / failed / rejected / circuit_open / quota_exceeded. rejected significa que o AnyHook recusou o evento (a verificação de assinatura falhou ou a URL de destino estava bloqueada); ele nunca foi tentado e não pode passar por replay.
• O código e o corpo da resposta HTTP do seu destino (por tentativa)
• Latência em milissegundos
• Número de tentativas e horário da próxima tentativa
• Se o evento é um replay (is_replay: true)

Quanto tempo os eventos ficam guardados depende do plano. Free: 3 dias, disponíveis para replay o tempo todo e depois excluídos. Pro: 1 ano: disponíveis para replay por 30 dias e depois em arquivamento criptografado, somente leitura. Scale: 7 anos: disponíveis para replay por 90 dias e depois em arquivamento criptografado, somente leitura. Enterprise: flexível.

Você pode fazer o replay de qualquer evento do log pelo painel, com um clique. O replay envia de novo o payload armazenado, byte a byte, ao destino para onde o evento foi, ou à nova URL desse destino, se você a mudou depois.

• Acesse Dashboard → Events
• Encontre o evento e clique no botão Replay
• O AnyHook cria um novo evento com is_replay: true, vinculado ao original

O AnyHook funciona com desenvolvimento local sem configuração extra, sem modo especial nem CLI. Duas abordagens:

1. Encaminhamento ao vivo por um túnel

Defina como destino do app uma URL de túnel que aponte para a sua máquina local. Qualquer provedor de túnel serve:

# ngrok
ngrok http 3000
# → https://abc123.ngrok.io

# cloudflared
cloudflared tunnel --url http://localhost:3000

# localhost.run
ssh -R 80:localhost:3000 nokey@localhost.run

Copie a URL do túnel para o destino do app no painel. O AnyHook encaminha os webhooks para lá exatamente como para qualquer outro endpoint: novas tentativas, log e cabeçalhos de assinatura funcionam do mesmo jeito.

2. Capture e faça o replay para o localhost

Deixe os eventos reais de produção se acumularem no AnyHook e faça o replay de qualquer um deles para o seu ambiente local quando precisar. Não é preciso disparar eventos de teste à mão: teste com payloads reais, quantas vezes o seu limite diário de replays permitir.

• Troque o destino pela URL do seu túnel
• Abra Dashboard → Events e clique no botão Replay de qualquer evento
• Ou use a API: POST /api/v1/events/{id}/replay
• O AnyHook envia o payload original, byte a byte, ao seu destino atual

Isso é especialmente útil para depurar casos extremos: encontre o evento problemático nos logs de produção, faça o replay dele localmente e repita até seu handler funcionar direito.

O AnyHook criptografa em repouso todos os dados de payload dos webhooks com AES-256-GCM antes que cheguem ao banco de dados. Isso inclui cabeçalhos de entrada, corpos de requisição e os segredos de assinatura de cada destino.

A criptografia usa uma chave dedicada (AES_SECRET_KEY), armazenada separadamente das credenciais do banco de dados. Um vazamento do banco sem a chave de criptografia só entrega texto cifrado: nenhum dado de webhook em texto puro, nenhum segredo de assinatura, nenhuma informação de cliente.

O AnyHook verifica as assinaturas dos webhooks na edge da Cloudflare, antes que o evento entre na fila. Quando um app tem seu segredo de assinatura, uma requisição com assinatura ausente ou inválida é recusada com um 401 e nunca consome sua cota; sem um segredo, as requisições são encaminhadas sem verificação.

A detecção da assinatura é automática, pelos cabeçalhos. Quando você cria um app e seleciona um tipo de origem, o AnyHook armazena o segredo de assinatura (criptografado em repouso) e usa o algoritmo certo para aquele provedor.

Origens não compatíveis ou personalizadas

Se a origem dos seus webhooks não está na lista de compatíveis, selecione Generic ao criar o app. O AnyHook vai:

• Aceitar e colocar na fila todo POST recebido, sem verificação de assinatura na entrada.
• Encaminhar ao seu destino o corpo byte a byte e os cabeçalhos originais do provedor, mais um cabeçalho AnyHook-Signature novo a cada tentativa. Removemos os cabeçalhos de infraestrutura adicionados antes da nossa edge (cf-* e afins).
• Anexar um cabeçalho AnyHook-Signature para que seu endpoint ainda possa verificar se a requisição passou pelo AnyHook.

Um app Generic não tem verificação de assinatura na entrada, seja qual for o segredo definido. O cabeçalho AnyHook-Signature prova que uma requisição passou pelo AnyHook, não quem a enviou ao AnyHook; se você precisa disso, mantenha sua própria verificação do cabeçalho original do remetente (encaminhado intacto). Se o remetente assina com o padrão Standard Webhooks (webhook-id, webhook-timestamp, webhook-signature, como fazem a OpenAI e a Replicate), escolha essa origem: ela é verificada na edge.

Três configurações opcionais em cada destino, todas no Pro e acima. Defina-as em App → Destinations → Delivery controls ou com PATCH /api/v1/apps/{slug} no objeto do destino. Uma conta Free mantém os controles que definiu enquanto pagava, mas não pode alterá-los.

{
  "destinations": [{
    "url": "https://api.example.com/hooks/stripe",
    "event_types": ["invoice.*", "checkout.session.completed"],
    "rate_limit": 20,
    "delay_seconds": 5
  }]
}

No Pro e no Scale, um app pode rodar seu próprio código a cada evento que recebe, num sandbox, sem um servidor seu. Ao salvar o código, o app ganha um destino que o executa, então as novas tentativas, o replay, o circuit breaker e o log de eventos funcionam como para qualquer destino, e a saída do console e o valor de retorno de cada execução são a resposta daquela entrega. Escreva o código na seção Code do app ou com os endpoints abaixo. Há modelos para ações comuns em /code-templates.md, e a migração do Pipedream tem um guia próprio.

export default async function (event, { env, store }) {
  // event: { method, headers, body, raw_body, delivery_id, attempt }
  console.log(event.body);
}

• O evento. body é o JSON já interpretado, os campos de formulário (urlencoded, ou os campos de texto de um formulário multipart) ou o texto bruto, e raw_body é o texto como chegou. method é sempre POST; a query string, o caminho e o IP de quem chamou não ficam guardados. delivery_id é o id X-AnyHook-Delivery do evento, e attempt conta a partir de 1, com 0 numa execução de teste.
• Falhas. Lançar uma exceção faz a entrega falhar, e o AnyHook tenta de novo dentro das tentativas do plano (Cronograma de novas tentativas). Uma nova tentativa de um evento cuja execução deu certo não roda o código de novo, mas, se a execução falhou depois que uma chamada já tinha sido feita, a nova tentativa roda o código de novo, então use o delivery_id como chave de idempotência dessas chamadas, onde a API permitir.
• Steps do Pipedream. export default defineComponent({ async run({ steps, $ }) {} }) também roda: steps.trigger.event é o evento acima, $.export e $.flow.exit funcionam, toda prop data_store é o store do app (um armazenamento chave-valor), o $auth.field de uma prop de app lê o segredo APP_FIELD, e qualquer outra prop lê o segredo com o nome dela (channelId lê CHANNEL_ID). O guia do Pipedream lista o que não é aproveitado.
• Pacotes npm. O AnyHook instala o que o código importa quando você salva, com a versão fixada do jeito do Pipedream (import axios from "axios@1.7.9"), até 20 pacotes. Um salvamento que instala pacotes novos pode levar alguns minutos; uma instalação que falha não salva nada.
• Segredos. Lidos como env.NAME ou process.env.NAME, até 20, com nomes de letras, dígitos e sublinhados, sem começar com dígito. PATH, HOME, NODE_OPTIONS, NODE_PATH, PWD e os nomes que começam com ANYHOOK_ pertencem ao runtime, e um valor tem no máximo 4.000 caracteres. Os valores nunca saem do servidor.
• O store. store.get, set (com { ttl } em segundos), has, delete, keys, entries e clear mantêm o estado entre eventos, um store por app: até 1.000 chaves de até 256 caracteres, cada valor com no máximo 64.000 bytes em JSON. Uma importação recebe {"entries": {key: value}}, sobrescreve as chaves que já existem e as grava sem TTL.
• Agendamentos. schedule são cinco campos de cron, em UTC, a não ser que venham prefixados com CRON_TZ=Area/City. Cada disparo posta um evento anyhook.schedule na própria URL do app, então conta como uma execução e como um evento, e só dispara enquanto o código está ligado. A origem do app precisa ser generic ou auto, sem segredo de assinatura: dê ao código agendado um app só para ele.
• E-mail. Todo app também recebe e-mails em {user-slug}.{app-slug}@anyhook.net, como um evento email.received cujo corpo traz from, to, subject, message_id, date, size e a mensagem MIME como raw. Como um agendamento, precisa de um app cuja origem seja generic ou auto, sem segredo de assinatura, e um e-mail acima do limite de payload do plano é devolvido.
• Páginas web e formulários. Uma página pode chamar a URL de entrada com fetch(): a edge responde ao preflight de CORS, e toda resposta leva Access-Control-Allow-Origin: *. Um formulário HTML simples precisa de method="post". Adicione ?redirect=https://your-site.com/thanks ao action dele e, quando o evento é armazenado, o visitante é levado para lá com um 303, desde que esse endereço esteja no site de onde o formulário foi enviado; caso contrário, o visitante vê uma página curta "Received". Os campos de texto chegam em event.body; os arquivos enviados se perdem.
• Limites. O código tem no máximo 64.000 bytes, e uma execução pode durar 105 s no Pro e 285 s no Scale. Uma execução guarda os últimos 16.000 caracteres da saída do console. As execuções do mês estão na tabela de planos, e toda execução conta, incluindo novas tentativas, execuções de teste, replays e disparos de agendamento. Não há excedente: passadas as execuções do mês, uma entrega ao código recebe 429 e fica retida (circuit_open), sem novas tentativas, pronta para o replay quando o mês virar ou o plano aumentar.
• Testes, ligar e desligar. POST .../code/test roda o código salvo no último evento armazenado do app, num event_id ou num body que você passar, e responde com os logs, o valor de retorno e a duração. Conta como uma execução e não entrega nada, mas o que o próprio código enviar acontece de fato. Os eventos só rodam o código enquanto ele está ligado. O painel salva código novo desligado, enquanto PUT .../code salva uma primeira versão já ativa, a não ser que você passe "enabled": false; um salvamento posterior mantém o estado atual. Enquanto outro destino ainda processa os mesmos eventos, como durante uma migração, salve com "enabled": false e ligue o código depois de remover esse destino. Qualquer uma das mudanças leva até um minuto para chegar a todos os locais da edge.

Toda requisição à API exige um token Bearer no cabeçalho Authorization:

Authorization: Bearer ahk_live_xxxxxxxxxxxxxxxx

Gere chaves de API em Dashboard → Settings → API Keys. As chaves valem para a sua conta, dão acesso total ou somente leitura (você escolhe ao criar cada uma) e podem ser revogadas a qualquer momento. Um app conectado pelo login do MCP (anyhook.net/mcp) pode chamar os mesmos endpoints com o token de acesso OAuth dele, dentro do acesso que você aprovou.

O AnyHook é um servidor MCP em https://anyhook.net/mcp, então um agente pode criar apps, ler o log de eventos e fazer o replay das falhas por você e, no Pro e no Scale, fazer deploy do código de um app e testá-lo (anyhook_code_deploy, anyhook_code_test, anyhook_code_get). Claude Code, claude.ai, Codex e VS Code se conectam com a URL e um login no navegador, sem chave para copiar: os passos para cada um.

O Cursor, o Windsurf e o Claude Desktop usam uma chave. Crie uma em Dashboard → Settings → API Keys, que mostra este trecho já com a sua chave:

{
  "mcpServers": {
    "anyhook": {
      "command": "npx",
      "args": [
        "-y",
        "anyhook-mcp"
      ],
      "env": {
        "ANYHOOK_API_KEY": "ahk_live_xxxxxxxxxxxxxxxx"
      }
    }
  }
}

Cursor: Settings → MCP → Add new MCP server, ou ~/.cursor/mcp.json. Windsurf: ~/.codeium/windsurf/mcp_config.json. Claude Desktop: Settings → Developer → Edit Config. As ferramentas de código precisam do anyhook-mcp 0.4.0 ou mais recente, que o npx -y busca, ou do servidor em https://anyhook.net/mcp.

Depois, peça: "Crie um app do AnyHook para os meus webhooks da Stripe e me passe a URL dele." Os agentes podem ler tudo isto em /llms.txt.

Veja todos os detalhes de preços →