Em 2023, analisamos as 100 principais empresas de API, juntamente com dados internos da Svix, para examinar com que frequência as melhores práticas de webhook são implementadas no setor e que tipo de impacto essas práticas têm na confiabilidade e escalabilidade dos sistemas de webhook. Este ano, analisamos as mesmas 100 empresas para ver se e quanto a adoção de webhooks e melhores práticas de implementação aumentou. Também analisamos mais de 100 novas empresas classificadas como startups pela Forbes em 3 setores diferentes: Fintech, Developer Tools e AI para comparar as taxas de adoção de webhooks entre setores, bem como pelo estágio da empresa. Estamos muito satisfeitos em relatar um aumento geral na adoção de webhook e implementação de melhores práticas. Gostaríamos de pensar que um dos principais fatores contribuintes para a tendência é o lançamento da especificação Standard Webook, que descreve as melhores práticas para um serviço de webhook de saída e a demanda contínua dos consumidores de webhook por webhooks mais confiáveis e seguros. Adoção de Webhook No ano passado, 83 das 100 principais APIs que analisamos ofereciam webhooks. Quando olhamos para as mesmas 100 APIs este ano, houve um pequeno aumento para 85% de adoção de webhooks. Uma pergunta que queríamos responder nesta edição do State of Webhooks era se as startups têm mais ou menos probabilidade de oferecer um serviço de webhook do que os provedores de API estabelecidos. Por um lado, as startups tendem a adotar novas tecnologias mais rapidamente, mas os webhooks tendem a ser um recurso adicionado após o lançamento de uma API. Pegamos as startups das listas Forbes Fintech 50 e AI 50, bem como as 59 principais listas de startups DevTool da Failory e as analisamos da mesma forma que fizemos com as 100 principais APIs. Claramente, as startups estão um pouco atrasadas na adoção de webhook, especialmente em IA, que tende a ser negócios mais focados no consumidor. Tentativas As novas tentativas (reenvio de um webhook se uma tentativa falhar) são um dos componentes fundamentais de um sistema de webhook confiável, por isso estamos felizes em ver um aumento na adoção de 67% para 73%. Também observamos aumentos no número de novas tentativas oferecidas, com uma diminuição no número de serviços que oferecem apenas 1 nova tentativa e aumentos no número de serviços que oferecem mais de 5 novas tentativas. Semelhante a como as startups estavam ficando para trás na adoção geral de webhook, elas também ficaram para trás na adoção de novas tentativas. Há uma taxa de adoção significativamente menor especificamente para startups Devtool, o que foi inesperado. A fintech representa a maior taxa de adoção de novas tentativas, o que faz sentido, dado o quão crítico é responder a eventos financeiros em tempo real e não perder nenhum dado de transação. Tentativas: Backoff exponencial Aumentar progressivamente o tempo de espera entre as tentativas reduz o risco de piorar os problemas do servidor, lida com problemas temporários enviando as primeiras tentativas rapidamente e dá aos usuários bastante tempo para corrigir endpoints com falhas. A adoção de um cronograma de espera exponencial para novas tentativas também aumentou de 25/83 (30%) para 31/83 (37%). A narrativa em torno da adoção de backoff exponencial para startups é muito semelhante à adoção de novas tentativas em geral. Startups de fintech lideram o caminho, com startups de Devtool ficando significativamente para trás. Tentativas manuais Em uma base de %, o maior aumento na adoção entre todas as melhores práticas que analisamos foi a implementação de novas tentativas manuais (+71%). Claro que foi a melhor prática menos adotada no relatório de 2023 e teve mais espaço para melhorias. Ser capaz de tentar novamente mensagens manualmente acelera a solução de problemas. É mais rápido disparar uma nova tentativa imediatamente em vez de esperar pela próxima nova tentativa automática. É uma tendência interessante de se ver e deve facilitar muito a vida dos consumidores de webhook ao solucionar problemas de endpoints com falhas ou simplesmente precisar enviar eventos de teste durante a configuração e os testes iniciais. Um dos resultados mais surpreendentes foi a taxa na qual startups de IA adotam novas tentativas manuais. Nosso melhor palpite sobre o motivo pelo qual a taxa de adoção entre startups de Fintech é tão baixa aqui em comparação com outras práticas recomendadas é que geralmente há um grande volume de mensagens em sistemas financeiros, então a capacidade de tentar novamente uma única transação raramente é necessária. Quando você tem um alto volume de mensagens, normalmente você vai querer tentar novamente todas as mensagens com falha em massa ou em lotes. Produtos de IA tendem a ter menor volume de mensagens. Registro e monitoramento Outro grande aumento percentual foi no número de serviços que oferecem logs de histórico de mensagens. Esse é um ótimo recurso que permite que os usuários façam o autoatendimento da solução de problemas de endpoints com falha. Isso não beneficia apenas o consumidor, que não precisa esperar uma resposta do suporte para saber por que não está recebendo os eventos esperados, mas também é benéfico para o provedor do webhook, pois ele recebe significativamente menos solicitações de suporte sobre falhas de webhook. Os problemas também são resolvidos mais rapidamente quando os desenvolvedores conseguem diagnosticar seus próprios problemas, então esse recurso é benéfico para todos. Tipos de eventos Outro resultado curioso é que a adoção de registro e monitoramento de mensagens é bastante uniforme entre os 100 principais provedores de API em comparação com startups e entre setores. Isso sugere que a capacidade de autodiagnosticar e solucionar falhas não é exclusiva de nenhum campo ou estágio específico da empresa, mas sim algo que todos os consumidores de webhook desejam e do qual se beneficiam muito. A adoção do tipo de evento foi essencialmente a mesma (93% vs 94%), já que a taxa de adoção era muito alta para começar. Isso ocorre simplesmente porque os tipos de evento são um recurso central de qualquer implementação de webhook, pois você precisa informar aos usuários qual evento eles estão recebendo. Curiosamente, a adoção do tipo de evento foi muito baixa para startups de IA. Na API 100, as únicas implementações sem webhooks foram aquelas com apenas um evento, então talvez as empresas de IA tenham apenas um evento para oferecer. Autenticação de mensagem Novamente, vemos um aumento na adoção das melhores práticas de autenticação de mensagens (HMACSHA256). Vemos esse aumento vindo de forma relativamente uniforme de uma diminuição em todos os métodos de autenticação alternativos, mas particularmente de implementações que estavam simplesmente passando um token Bearer. A adoção do HMACSHA256 é semelhante em todos os aspectos. Os resultados atípicos vêm do AI 50, onde passar um segredo diretamente no cabeçalho é muito popular. Curiosamente, isso explica como poucos AI 50 não oferecem autenticação de webhook. Mensagem de autenticação: carimbos de data/hora Incluir o timestamp como parte do conteúdo hash ao gerar assinaturas HMAC ajuda a evitar ataques de repetição. Sem o timestamp como parte da assinatura, mensagens antigas podem ser duplicadas e enviadas novamente, o que pode ser um grande problema se uma instituição financeira processar a mesma transação duas vezes. Mais do mesmo com timestamps na assinatura. Provedores de API estabelecidos superam startups quando se trata de implementar melhores práticas. Documentação Uma boa documentação é essencial para fornecer uma excelente experiência ao desenvolvedor. Isso é especialmente verdadeiro para webhooks que têm várias “armadilhas” nas quais os desenvolvedores podem cair ao tentar implementar seus endpoints. Ter uma documentação extensa pode ajudar os usuários a evitar essas armadilhas e economizar muito tempo e frustração. Uma coisa que vemos nos melhores serviços de webhook são instruções sobre testes. Isso também inclui dicas de solução de problemas para problemas comuns, como falha na verificação de assinatura. Quando se trata de documentação, startups estão no mesmo nível de provedores de webhook mais estabelecidos. Isso também é lógico, pois a documentação é fundamental para todos os produtos. Um elemento-chave que vemos como um indicador de boa documentação de webhook são os exemplos de código. Isso se aplica à maioria da documentação de API, mas particularmente para webhooks. É extremamente útil ter exemplos de endpoints de webhook funcionando para que os usuários entendam exatamente o que seus endpoints precisam fazer e como fazê-lo. Junto com tudo o mais que vimos no relatório até agora, também vimos mais amostras de código. Isso é um reflexo direto do aumento no número de provedores que oferecem autenticação de assinatura HMAC. Se os provedores não oferecem autenticação alguma ou estão oferecendo métodos mais simples, como autenticação básica ou um cabeçalho secreto simples, há menos necessidade de uma amostra de código, pois a implementação é muito mais simples. Aqui, a maioria dos provedores de webhook, sejam eles estabelecidos ou startups, estão oferecendo amostras de código para seus usuários. A exceção são as empresas de IA que tendem a não oferecer assinaturas HMAC e se inclinam para cabeçalhos secretos para autenticação. Talvez os usuários de IA não sejam tão técnicos ou conscientes da segurança quanto os consumidores de Fintech e Devtool e um método de autenticação mais simples seja melhor para seu caso de uso. Também parece provável que os produtos de IA tenham uma base de usuários principais de consumidores e suas APIs e webhooks sejam uma oferta secundária para uma pequena % de seus usuários e, portanto, menos esforço foi investido para tornar seus serviços de webhook mais seguros/robustos. Resumo e principais conclusões Temos o prazer de informar que, após atualizar nossa pesquisa, observamos um aumento geral na adoção e na implementação de melhores práticas. Observamos que o número de novos adotantes foi consistente em todas as práticas recomendadas, o que mostrou que a maior parte do aumento na adoção veio de novas implementações que seguiram a maioria das práticas recomendadas, em oposição às implementações existentes que atualizaram seus serviços de webhook. Este ano, analisamos mais 150 empresas de 3 listas diferentes de startups importantes em Fintech, Devtools e IA para ver se poderíamos encontrar alguma tendência entre os setores, bem como diferenças entre startups e provedores de API estabelecidos. Em geral, vimos que os provedores de API estabelecidos adotam webhooks em uma taxa maior e também implementam mais práticas recomendadas. Isso é muito lógico, pois os provedores estabelecidos têm mais recursos para investir na oferta de uma solução melhor e as startups têm mais probabilidade de lançar versões MVP (produto mínimo viável) de seus serviços de webhook.
