A URL do seu túnel muda a cada reinício. A do seu webhook não precisa mudar.

Você roda o comando ngrok http 3000. Copia a URL. Cola no Dashboard da Stripe. Depura por uma hora, fecha o notebook e, na manhã seguinte, o ritual inteiro se repete porque a URL sumiu.

Não é um problema difícil. É um pequeno corte que reabre todo santo dia, e a maioria das respostas é "pague por um domínio estático" ou "use outro túnel". Existe uma terceira opção que não custa nada e resolve isso em outra camada.

Cadastre um endereço que sobrevive ao terminal

O provedor não precisa saber onde seu notebook está. Ele precisa de uma URL que esteja sempre lá.

Stripe / Shopify / GitHub
        │
        ▼
in.anyhook.net/you/dev      ← registered once, never changes
        │
        ▼
https://whatever-ngrok-gave-you-today.ngrok-free.app/webhook

O provedor fala com a metade permanente. Você troca a metade temporária sempre que seu túnel reinicia, num único campo, sem mexer no painel do provedor. A mudança chega a todos os pontos da edge (o Cloudflare Worker que atende a URL permanente) em cerca de um minuto.

A ideia é só essa. O resto do texto explica por que vale os cinco minutos, e onde isso não ajuda.

A Shopify transforma isso em mais que um pequeno corte

Na maioria dos provedores, uma URL desatualizada significa entregas com falha que você pode ignorar. Na Shopify, pode significar perder a inscrição.

Uma inscrição criada pela Admin API da Shopify mantém a URL com que foi criada. Você inicia seu servidor de desenvolvimento, ganha uma URL de túnel nova, e a inscrição continua apontando para o endereço de ontem. A Shopify entrega para ele, falha, tenta de novo e, depois de falhas consecutivas suficientes, exclui a inscrição por completo. Agora nada chega, mesmo depois que você conserta o túnel, e a falha parece "a Shopify parou de enviar", e não "eu mudei minha URL".

O WooCommerce desativa um webhook depois de mais de cinco falhas consecutivas. A Stripe desativa um endpoint depois de falhas contínuas. Uma URL que muda todo dia é uma máquina de produzir falhas consecutivas.

O que isso faz e um domínio estático pago não faz

Um domínio de túnel estático resolve o colar de novo. Não resolve a parte em que seu notebook está fechado.

Com um relay de webhooks (um serviço que recebe, guarda e encaminha seus webhooks) na frente, o relay recebe, verifica e grava num log os eventos que chegam enquanto seu túnel está fora do ar, antes de tentar qualquer entrega. A entrega para sua máquina falha, o que é esperado e não tem problema. O evento continua lá.

• Volte, inicie o túnel e clique em Replay (um novo envio de um evento armazenado, feito por você). Os eventos que falharam enquanto você estava fora são enviados de novo para seu handler, do mais antigo para o mais novo
• Os replays não contam na sua cota mensal, embora tenham um limite diário e usem sua franquia de computação
• Você vê exatamente o que o provedor enviou, cabeçalhos e corpo, em vez de deduzir isso a partir de um handler que nunca rodou

O plano Free tem um app (uma URL de entrada para uma origem), 10.000 eventos por mês e 1.000 por dia, mais do que um ciclo de desenvolvimento usa. Os eventos ficam disponíveis para replay por três dias nesse plano, e esse é o limite honesto: é uma rede de segurança para o fim de semana, não um arquivamento.

Onde isso não ajuda

• Isso não mantém seu handler rodando. Enquanto o túnel está fora do ar, as entregas para ele falham. O que você ganha é o log e o botão de replay, não a entrega para uma máquina desligada
• Não é motivo para pular a verificação de assinatura. O AnyHook encaminha intactos os cabeçalhos originais do provedor, então a assinatura que você verificava continua sendo a assinatura que você verifica
• Em produção, o túnel não deveria existir. Esse é outro argumento, e o fizemos em Por que o ngrok não basta. O ngrok continua sendo a ferramenta certa para o ciclo de desenvolvimento; este texto trata só da troca constante de URL que ele causa

Como configurar

1. Crie um app. Você recebe in.anyhook.net/{you}/{app} na hora
2. Coloque essa URL no painel do provedor uma vez
3. Defina como destino a URL atual do seu túnel
4. Envie um evento de teste pela página do app e veja-o chegar

Amanhã, quando o túnel der a você um endereço novo, você muda o passo 3 e mais nada. Se depois você renomear o app ou sua conta, a URL antiga continua roteando em vez de dar 404, porque uma URL que você já entregou a um provedor nunca deveria parar de funcionar.

Conclusão

O painel do provedor é o lugar errado para guardar um endereço que muda todo dia. Coloque ali algo permanente, mantenha a parte temporária do seu lado, e o ritual diário vai embora junto com os contadores de entregas com falha que ele alimentava em silêncio.

Se você quer a versão mais aprofundada disso, a que fala de verificação de assinatura que sobrevive às novas tentativas (retries) e do que fazer quando um provedor já desativou você, comece por Como verificar assinaturas de webhook e Como fazer o replay de um webhook.