# Melhores práticas para usar webhooks

Siga estas melhores práticas para melhorar a segurança e o desempenho quando usar webhooks.

## Inscreva-se no número mínimo de eventos

Você só deve se inscrever nos eventos de webhook de que necessita. Isso reduzirá a quantidade de trabalho que seu servidor precisará executar. Para obter mais informações sobre como assinar eventos, confira [Criação de webhooks](/pt/enterprise-server@3.22/webhooks/using-webhooks/creating-webhooks) e [Editando webhooks](/pt/enterprise-server@3.22/webhooks/using-webhooks/editing-webhooks).

## Usar um segredo de webhook

> \[!WARNING]
> Para evitar a exposição acidental de informações sensíveis, **não** inclua informações confidenciais na URL do payload.
> Isso inclui suas chaves de API e outras credenciais de autenticação. Para validar que as entregas de webhook foram enviadas pelo GitHub e não foram adulteradas, use um segredo de webhook. Para saber mais, confira [Validação de entregas de webhooks](/pt/enterprise-server@3.22/webhooks/using-webhooks/validating-webhook-deliveries).

O segredo do webhook deve ser uma sequência de caracteres aleatória com alta entropia. Você deve armazenar com segurança seu segredo de webhook de uma maneira que seu servidor possa acessar.

## Usar verificação HTTPS e SSL

Você deve garantir que seu servidor use uma conexão HTTPS. Por padrão, GitHub verificará certificados SSL ao fornecer webhooks.
GitHub recomenda que você deixe a verificação SSL habilitada.

## Responder dentro de 30 segundos

Seu servidor deve responder com resposta 2XX no prazo de 30 segundos após receber uma entrega de webhook. Se o servidor demorar mais do que isso para responder, encerrará GitHub a conexão e considerará a entrega uma falha.

Para responder em tempo hábil, convém configurar uma fila para processar conteúdo de webhook de forma assíncrona. Seu servidor pode responder ao receber o webhook e, em seguida, processar o conteúdo em segundo plano sem bloquear futuras entregas de webhook. Por exemplo, você pode usar serviços como <c0>Hookdeck</c0> ou bibliotecas como <c1>Resque</c1> (Ruby), < <c2>RQ</c2> (Python) ou <c3>RabbitMQ</c3> (Java).

## Verifique o tipo de evento e a ação antes de processar o evento

Há vários tipos de evento de webhook e muitos eventos podem ter vários tipos de ação.
GitHub continua a adicionar novos tipos de eventos e novas ações aos tipos de eventos existentes. Seu aplicativo deve verificar o tipo de evento e a ação de um conteúdo de webhook antes de processar o conteúdo. Para determinar o tipo de evento, você pode usar o cabeçalho de solicitação `X-GitHub-Event`. Para determinar o tipo de ação, você pode usar a chave `action` de nível superior no conteúdo do evento.

## Reentregar entregas perdidas

Se o servidor ficar inoperante, você deverá reenviar os webhooks perdidos assim que o servidor voltar a funcionar. Para saber mais, confira [Entregar webhooks novamente](/pt/enterprise-server@3.22/webhooks/testing-and-troubleshooting-webhooks/redelivering-webhooks).

## Usar o cabeçalho `X-GitHub-Delivery`

Em um ataque de reprodução, um agente mal-intencionado intercepta uma entrega de webhook e reenvia a entrega. Para proteção contra ataques de repetição, você pode usar o cabeçalho `X-GitHub-Delivery` para garantir que cada entrega seja única por evento.

> \[!NOTE]
> Se você solicitar uma reentrega, o cabeçalho `X-GitHub-Delivery` será o mesmo que na entrega original.

## Leitura adicional

* [Práticas recomendadas para usar a API REST](/pt/enterprise-server@3.22/rest/using-the-rest-api/best-practices-for-using-the-rest-api)
* [Práticas recomendadas para criar um aplicativo GitHub](/pt/enterprise-server@3.22/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app)