Skip to main content
Receba eventos da YCloud em um endpoint público e processe-os sem perder ou duplicar ações de negócios. Use HTTPS para produção, preserve o corpo bruto da requisição e verifique cada assinatura antes de aceitar o evento.

Registrar seu endpoint

No Console da YCloud, abra Desenvolvedores > Webhook, selecione Adicionar Endpoints, insira a URL dos Endpoints, selecione Eventos e salve com Confirmar. Você também pode usar POST /v2/webhookEndpoints; consulte Configurar webhooks para ver a requisição e a resposta.
  • Você pode configurar até 20 endpoints por conta.
  • A URL deve ser acessível publicamente e não deve resolver para um endereço privado.
  • A URL suporta até 500 caracteres; a descrição opcional suporta até 400.
  • Guarde em segurança o segredo de assinatura secret retornado.

Ler a requisição do evento

Para obter exemplos completos, consulte Cargas úteis de webhook.

Verificar a assinatura

O cabeçalho YCloud-Signature tem o formato t=TIMESTAMP,s=SIGNATURE. O timestamp é a hora Unix em segundos.
  1. Extraia t e s do cabeçalho.
  2. Junte o timestamp, um ponto final e os bytes exatos do corpo bruto da requisição.
  3. Calcule o HMAC-SHA256 com o segredo de assinatura do endpoint.
  4. Compare o resultado hexadecimal usando uma comparação de tempo constante.
Não serialize o JSON analisado para reconstruir o corpo. Espaços em branco, ordem das chaves ou escape de Unicode alteram a entrada da assinatura. O exemplo abaixo também usa uma tolerância de timestamp configurável de cinco minutos para reduzir o risco de repetição (replay). Essa tolerância é uma política da aplicação, não um prazo de repetição da YCloud. Mantenha o relógio do seu servidor sincronizado.

Aceitar antes de confirmar

Persista o evento validado em uma fila durável ou em uma caixa de entrada transacional antes de retornar 2xx. Se o armazenamento estiver indisponível, retorne uma falha para que a entrega possa ser repetida. Após a aceitação durável, deixe seu worker lidar com falhas de processamento de negócios com suas próprias tentativas. Este manipulador Express usa uma operação persistEvent fornecida pela aplicação. Implemente-a como uma inserção atômica com chave definida pelo id do evento; um evento já armazenado deve contar como sucesso. Não marque um evento como processado antes que sua transação de negócio seja confirmada.

Exemplo em Java e Spring

Este exemplo em Java 17 aplica a mesma ordem de verificação e aceitação durável. Forneça um bean EventInbox suportado por um armazenamento transacional com uma restrição de unicidade no ID do evento. insertIfAbsent deve confirmar o evento completo antes de retornar; IDs duplicados retornam com sucesso. O seu worker pode então processar e marcar os eventos armazenados em sua própria transação.
Não use uma gravação separada “já processado” no Redis antes de enfileirar o evento: se o enfileiramento falhar após essa gravação, uma nova tentativa poderá ser descartada. Use uma caixa de entrada durável e atômica ou uma fila cuja aceitação e tratamento de duplicatas sejam atômicos.

Tempo de resposta, tentativas e suspensão

Retorne uma resposta 2xx prontamente; mire em menos de 6 segundos. Respostas lentas acima de 10 segundos podem reduzir a prioridade de entrega. Não execute tarefas de negócios lentas dentro do manipulador HTTP. Para uma resposta diferente de 2xx ou ausência de resposta, os intervalos padrão de nova tentativa são: A YCloud interrompe as tentativas para esse evento após atingir o limite configurado. Com as configurações padrão, uma URL pode ser suspensa por 3 minutos quando atinge 200 falhas por minuto ou 10 minutos de tempo acumulado de falha em um minuto em requisições simultâneas. As requisições são pausadas durante a suspensão e retomadas em seguida. Monitore também o status do endpoint. Um endpoint com status pending não recebe eventos; consulte configuração de endpoints.

Verificar o seu receptor

  • Uma assinatura válida e um evento armazenado de forma durável retornam 2xx.
  • Corpos modificados, assinaturas malformadas e timestamps desatualizados são rejeitados.
  • Um evento duplicado é aceito sem repetir sua ação de negócio.
  • Uma falha no armazenamento retorna erro e permite uma nova tentativa de entrega.
  • Tipos de eventos desconhecidos não causam falhas no receptor.
  • Falhas de processamento são repetidas pelo seu worker após a aceitação.
  • Segredos e payloads completos de clientes não são gravados nos logs da aplicação.