Skip to main content
Quem tem app e site, ou mais de uma marca, tem mais de uma integração. O backend é um só; a chave, o fluxo e o segredo do webhook não.

Confira o exemplo

Os arquivos desta POC, com o destino de cada um.

Por que não uma chave só

Uma chave por canal é o que faz um vazamento no app não alcançar o site, e o webhook de homologação não disparar no endpoint de produção. É também o que deixa você revogar a chave de um canal sem derrubar o outro.

O registro de canais

lib/channels.ts

Criar no canal certo

app/api/verifications/route.ts
Nunca deixe o cliente escolher o canal pelo corpo da requisição. Quem manda o canal manda a chave usada, e com isso escolhe em qual conta a verificação nasce.

Um endpoint de webhook por canal

A rota carrega o canal no caminho, e cada uma confere contra o seu próprio segredo:
app/api/webhooks/[channel]/route.ts
No dashboard, cada integração aponta o webhook dela para o seu caminho: https://seu-dominio/api/webhooks/site e https://seu-dominio/api/webhooks/app.
Um endpoint por canal e não um endpoint com vários segredos: tentar cada segredo até um bater transforma uma falha de assinatura em algo indistinguível de um canal mal configurado.

Antes de rodar

.env
Use uma integração sandbox. Nenhum dos três valores vai para o browser ou para o app. Nesta POC cada variável ganha o sufixo do canal:
.env

O que esta POC não faz

POC é código para entender o fluxo, não para copiar em produção. Em todas elas, authenticate() é um stub, db é um objeto de mentira e não há migration, observabilidade nem retentativa própria.
  • Canais fixos em código. Com muitos canais, isso vira tabela e cache.
  • Sem rotação de chave por canal sem downtime.
  • Sem métrica separada por canal.

Próximo passo

Integrações

Ambientes, origens, chaves e aparência.

Cadastrar webhooks

Escopo por integração e por conta.