Overview
The retry endpoint allows you to reattempt a failed transfer that is marked as retriable within a bulk transfer batch. This is useful when transfers fail due to temporary issues like network problems or bank system downtime.Only transfers with
retryable: true in their status can be retried. Non-retriable failures (like invalid account numbers) cannot be retried.Endpoint
Path Parameters
Example Request
Response
Error Responses
404 - Transfer Not Found
404 - Transfer Not Found
400 - Not Retriable
400 - Not Retriable
409 - Already Being Retried
409 - Already Being Retried
Retry Limits
- Maximum 3 retry attempts per transfer
- 5-minute wait period between retries
- 24-hour maximum retry window from initial failure
- Retries count towards daily transfer limits
Status Transitions
- Initial failed status:
failedwithretryable: true - After retry request:
processing - Final status:
- Success:
succeeded - Failure:
failed(may be retriable again)
- Success:
Webhook Events
Monitor these events for retry status:bulk.transfer.retry.started- Retry attempt initiatedbulk.transfer.retry.succeeded- Retry completed successfullybulk.transfer.retry.failed- Retry attempt failed
Best Practices
-
Retry Strategy
- Implement exponential backoff between retries
- Track retry attempt count
- Consider time of day for retries
- Monitor success rates by failure reason
-
Error Handling
- Log all retry attempts
- Track retry outcomes
- Handle webhook notifications
- Monitor retry limits
-
User Communication
- Notify users of retry status
- Provide clear error messages
- Suggest alternative actions for non-retriable failures
- Set expectations for processing time
Need Help?
For retry-related assistance:
- Check our Error Handling guide
- Contact Support
- Review Webhook Events