Retries

Há no máximo 10 tentativas (MAX_DELIVERY_ATTEMPTS). A primeira tentativa já nasce com attempt_number 1. Se a tentativa 10 falha, a entrega é abandonada. Não existe uma 11ª tentativa.

O que volta a ser tentado

Somente estes status são retentáveis: 408, 425, 429 e 500–599. Exceção de transporte vira status 599 e entra nessa faixa. Alvo bloqueado por SSRF (host privado ou IP interno) vira status 0 e não é retentável. Falha de resolução DNS vira IOException, status 599, e também é retentável.

Todo o resto é abandono imediato, inclusive 3xx e a maior parte dos 4xx. O cliente não segue redirect.

Espera entre falhas

Depois das tentativas 1 a 9, a espera base é, nesta ordem: 30 segundos, 5 minutos, 30 minutos, 2 horas, 6 horas, 12 horas, 24 horas, 48 horas e 120 horas. O jitter é de ±20% (base / 5), derivado do UUID da entrega. Não há fila separada além desse agendamento.

O varredor roda com atraso fixo padrão de 30 segundos (gateway.webhooks.dispatcher-delay-ms), pega até 50 entregas vencidas e no máximo 5 por lojista. O lease padrão é 15 minutos (gateway.webhooks.lease-seconds, 900). Cada HTTP aplica os mesmos 10 segundos ao connect e a cada leitura do socket, sem prazo total da tentativa.

Circuito

Dez falhas consecutivas no endpoint abrem o circuito por 1 hora. Sucesso zera o contador. Enquanto o circuito está aberto, entregas vencidas não são reivindicadas. O reset manual fica no dashboard de QA, na seção Webhooks. Essa ação não faz parte do OpenAPI de chave sk_*.

Responda 2xx só depois de persistir o efeito de id. Um 2xx tardio não desfaz uma entrega já abandonada.