Webhooks do Workspace: entrega isolada de eventos para cada cliente na sua plataforma

Se está a executar um SaaS multi-tenant na Firma.dev, provavelmente já se deparou com este obstáculo antes. Um webhook ao nível da empresa recebe eventos para cada pedido de assinatura em todas as áreas de trabalho, e o seu backend tem de os distribuir para o cliente certo. Funciona bem quando controla ambos os lados. Deixa de funcionar no momento em que os seus clientes querem os seus próprios endpoints de webhook apontados para os seus próprios sistemas.

Os Webhooks de Área de Trabalho resolvem isso. Cada área de trabalho pode agora definir os seus próprios endpoints de webhook com segredos de assinatura independentes, totalmente separados dos webhooks ao nível da empresa. Esta é a peça que faz com que o modelo multi-tenant da Firma.dev funcione realmente de ponta a ponta.

O problema multi-tenant que isto resolve

As Áreas de Trabalho de Cliente sempre lhe deram espaços particionados para cada cliente na sua plataforma. Cada área de trabalho tem os seus próprios templates, a sua própria utilização de envelopes, a sua própria chave de API. Separação limpa. Mas, até agora, o envio de webhooks era a exceção. Cada evento era encaminhado através de um único webhook ao nível da empresa, o que significava que a sua plataforma era sempre o intermediário para as notificações.

Isso é aceitável para algumas arquiteturas. É um impedimento absoluto para outras. Pense numa plataforma que permite aos seus clientes ligar os seus próprios CRMs, ERPs ou sistemas de ticketing. Cada cliente quer que os eventos de assinatura sejam enviados diretamente para o seu próprio stack. Ou considere um revendedor que oferece aos clientes finais um isolamento real em todas as suas integrações. Ou uma equipa de desenvolvimento que quer áreas de trabalho de staging a disparar eventos para um endpoint de teste enquanto a produção dispara para o real.

Em todos estes casos, o webhook tem de residir ao nível da área de trabalho, caso contrário, todo o modelo falha.

O que está disponível por área de trabalho

Cada área de trabalho tem agora acesso ao conjunto completo de ferramentas de webhook, limitado a si própria:

• CRUD completo em endpoints de webhook

• O seu próprio segredo de assinatura, com um período de tolerância de rotação de 7 dias quando o regenera

• Envio de testes, para que possa verificar a configuração sem disparar eventos reais

• Um registo de eventos por área de trabalho

• Uma opção para "Ignorar Webhooks da Empresa" se quiser que os webhooks de área de trabalho substituam totalmente o envio ao nível da empresa, em vez de funcionarem em paralelo

Esta última opção é mais importante do que parece. Algumas equipas querem que os webhooks da empresa e da área de trabalho disparem em simultâneo, porque a sua plataforma ainda precisa de uma visão global dos eventos enquanto os clientes recebem os seus próprios fluxos. Outras equipas querem um isolamento limpo onde os webhooks de área de trabalho são a única fonte de verdade. Pode escolher por área de trabalho.

Segurança: proteção contra SSRF em todos os URLs de webhook

Algo que vale a pena destacar para os programadores que estão a avaliar isto. Toda a validação de URLs de webhook inclui agora proteção SSRF, que bloqueia gamas de IPs privados, endpoints de metadados de cloud e tentativas de reencaminhamento de DNS. Quando permite que os seus clientes configurem os seus próprios endpoints de webhook dentro de áreas de trabalho que controlam, isto não é opcional. Um cliente poderia acidentalmente (ou deliberadamente) apontar um webhook para 169.254.169.254 ou para um IP interno e, sem a proteção SSRF, estaria a reencaminhar pedidos da infraestrutura da Firma para locais onde ninguém deveria aceder.

Isto é tratado na camada da plataforma, pelo que não precisa de construir defesas por si próprio.

Interface da API

Algumas adições do lado da API:

• Parâmetro workspace_id em POST /webhooks e GET /webhooks para que possa limitar as operações de webhook a uma área de trabalho específica

• Novos endpoints para gerir segredos de webhooks de área de trabalho: POST /workspaces/{id}/webhooks/rotate-secret e GET /workspaces/{id}/webhooks/secret-status

• Cinco novos campos na resposta de GET da área de trabalho que cobrem o estado de configuração do webhook

Os detalhes completos encontram-se no registo de alterações da API para a v1.15.0.

Quando utilizar webhooks de área de trabalho vs. webhooks de empresa

Modelo mental rápido:

Os webhooks de empresa servem para a sua plataforma. Qualquer coisa sobre a qual a sua aplicação principal precise de saber, em todos os clientes, deve fluir através do envio ao nível da empresa. Eventos de faturação, registo de conformidade, análise, fluxos de trabalho internos.

Os webhooks de área de trabalho servem para os seus clientes. Qualquer coisa à qual os sistemas de um cliente específico precisem de reagir deve fluir através do envio ao nível da área de trabalho. Atualizações de CRM, notificações específicas do cliente, integrações de terceiros que eles próprios configuraram.

Ambos podem coexistir na mesma área de trabalho, ou pode optar por excluir totalmente uma área de trabalho dos webhooks da empresa. Para a maioria das plataformas multi-tenant, o padrão correto são os webhooks de empresa para eventos críticos da plataforma, juntamente com os webhooks de área de trabalho que os seus clientes configuram através da sua interface de utilizador.

Começar

Se já utiliza as Áreas de Trabalho de Cliente, pode começar a adicionar webhooks de área de trabalho hoje mesmo. As integrações de webhooks existentes ao nível da empresa continuam a funcionar exatamente como antes. Isto é puramente cumulativo.

Comece a utilizar a Firma.dev gratuitamente, sem necessidade de cartão de crédito. Sem contratos, sem mínimos, e com o conjunto completo de ferramentas multi-tenant, incluindo Áreas de Trabalho de Cliente e Webhooks de Área de Trabalho, desde o primeiro dia.