Visão Geral
Reenvia manualmente os webhooks de atualização de status para boletos que já foram processados. Útil para recuperar notificações perdidas ou testar integrações.Este endpoint reenvia apenas webhooks de status finais (
PAID, WAITING_PAYMENT, CANCELED). Status intermediários como PENDING são ignorados.Casos de Uso
- Webhook perdido: Quando seu servidor não recebeu a notificação original
- Retry após downtime: Reprocessar notificações perdidas durante uma manutenção
- Teste de integração: Validar tratamento de webhooks sem criar novos boletos
- Debug: Reenviar notificação específica para análise
Parâmetros da Requisição
Você pode especificar pagamentos por período OU por lista de IDs. Pelo menos um dos dois métodos deve ser fornecido.
Filtro por Período
Data inicial do período de buscaExemplo:
2024-01-01Obrigatório se
endDate for fornecido. Não pode ser usado junto com paymentIds.Data final do período de buscaExemplo:
2024-01-31Obrigatório se
startDate for fornecido. Não pode ser usado junto com paymentIds.Filtro por IDs
Lista de IDs dos pagamentos (UUIDs)Exemplo:
["550e8400-e29b-41d4-a716-446655440000", "6ba7b810-9dad-11d1-80b4-00c04fd430c8"]Obrigatório se
startDate e endDate não forem fornecidos.Status Processados
| Status | Webhook Reenviado? | Motivo |
|---|---|---|
PAID | ✅ Sim | Status final - pagamento confirmado |
WAITING_PAYMENT | ✅ Sim | Boleto emitido aguardando pagamento |
CANCELED | ✅ Sim | Status final - boleto cancelado |
PENDING | ❌ Não | Status intermediário - sem webhook |
PROVIDER_CREATION_ERROR | ❌ Não | Erro técnico - sem webhook |
PROVIDER_CANCEL_ERROR | ❌ Não | Erro técnico - sem webhook |
Resposta de Sucesso
Mensagem de confirmaçãoValor:
"Payment updates sent successfully"O endpoint retorna sucesso mesmo se alguns webhooks falharem. Verifique os logs para detalhes de falhas individuais.
Exemplo de Requisição
Reenviar por Período
cURL
JavaScript
Python
Reenviar por Lista de IDs
cURL
JavaScript
Python
Exemplo de Resposta
Códigos de Resposta
Webhooks enviados com sucesso
Alguns webhooks individuais podem ter falhado. Verifique os logs para detalhes.
Requisição inválidaPossíveis causas:
- Nem
startDate/endDatenempaymentIdsforam fornecidos startDatefornecido semendDate(ou vice-versa)- Formato de data inválido
API key inválida ou ausente
Nenhum pagamento encontrado com os critérios fornecidos
Erro interno do servidor
Erros Comuns
Nenhum pagamento encontrado
Nenhum pagamento encontrado
Parâmetros ausentes
Parâmetros ausentes
Data incompleta
Data incompleta
Comportamento e Limitações
Webhooks Reenviados
Para cada status, o webhook contém: PAID (Pagamento Confirmado):Falhas e Retries
- ✅ Tentativas são feitas em paralelo (Promise.allSettled)
- ✅ Falhas individuais são logadas mas não interrompem o processo
- ✅ Retorna sucesso mesmo se alguns webhooks falharem
- ❌ Não há retry automático - se falhar, você deve chamar o endpoint novamente
Performance
- Para períodos longos (muitos pagamentos), o processo pode demorar
- Máximo recomendado: ~100 pagamentos por requisição
- Considere filtrar por períodos menores se tiver volume alto
Boas Práticas
Use Períodos Curtos
Filtre por períodos de 7-30 dias para evitar timeout
IDs Específicos
Para reenvios pontuais, use
paymentIds ao invés de períodoMonitore Logs
Verifique logs da aplicação para detalhes de falhas
Webhook URL Válido
Garanta que seu webhook URL esteja configurado e acessível
Monitoramento
Os logs incluem informações detalhadas:Logs de Erro
Para webhooks que falharam:Próximos Passos
- Configurar Webhook URL: Configuração de Webhooks
- Emitir Boletos: Criar Boleto
- Pagar Boletos: Pagar Boleto
- Consultar Status: Listar Pagamentos