Reprocessar delivery
Reenvia uma entrega já concluída e devolve o desfecho da nova tentativa.
POST /webhooks/deliveries/:id/retry
Faz parte do recurso Webhooks — o cadastro e o catálogo de eventos estão lá.
Reenvia uma entrega para a URL atual do webhook. O caso de uso é o de sempre: seu endpoint
esteve fora do ar, você corrigiu, e agora quer receber o que ficou para trás. Responde 200 com a
entrega relida depois do reenvio.
failed é o caso normal; success também é aceito, para quando você
processou mal e quer o evento de novo. As que ainda estão em curso (pending, retrying)
respondem 409 DELIVERY_ALREADY_RUNNING — a Z2Pay já vai reenviá-las sozinha, sem você pedir.id, mesmo occurredAt. Se o recurso
mudou de estado desde então, o payload continua descrevendo o momento do evento, não o de agora.
Um receptor que trate o webhook como aviso e consulte a API pelo id não se incomoda com isso.Limites e recusas
Cada entrega tem 12 tentativas no total: as 7 do ciclo automático mais 5 reprocessamentos manuais. O reenvio recusa com código próprio, para você distinguir o que fazer:Exemplo
Authorizations
API Key da Credential (gerada no Backoffice)
Headers
Chave única para garantir idempotência da requisição
Path Parameters
ID da delivery
Response
Entrega reenviada, com o resultado da nova tentativa
Identificador único do registro.
ID do webhook relacionado ao registro.
Tipo do evento entregue (ex.: transaction.paid).
URL de destino do webhook ou link de download do arquivo.
Conteúdo (payload) enviado na entrega do webhook.
Situação da entrega. Valores: pending, success, failed, retrying.
Número de tentativas de entrega já realizadas.
Código de status HTTP retornado pelo endpoint na entrega.
Corpo da resposta retornada pelo endpoint na entrega.
Mensagem de erro quando o processamento falha.
Data e hora da última tentativa de entrega (ISO 8601).
Data e hora de criação do registro (ISO 8601).
Data e hora da última atualização do registro (ISO 8601).