Retry Transfer

​

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.

​

Endpoint

POST /bulk-transfers/{batch_id}/transfers/{id}/retry

​

Path Parameters

​

Example Request

curl -X POST "https://api.spendjuice.com/bulk-transfers/{batch_id}/transfers/{id}/retry" \
-H "Authorization: Bearer YOUR_API_KEY"

​

Response

​

Error Responses

{
  "error": {
    "code": "transfer_not_found",
    "message": "No transfer found with the provided ID"
  }
}

{
  "error": {
    "code": "not_retriable",
    "message": "This transfer cannot be retried"
  }
}

{
  "error": {
    "code": "retry_in_progress",
    "message": "Transfer is already being retried"
  }
}

​

Retry Limits

​

Status Transitions

1. Initial failed status: failed with retryable: true
2. After retry request: processing
3. Final status:
   • Success: succeeded
   • Failure: failed (may be retriable again)

​

Webhook Events

Monitor these events for retry status:

• bulk.transfer.retry.started - Retry attempt initiated
• bulk.transfer.retry.succeeded - Retry completed successfully
• bulk.transfer.retry.failed - Retry attempt failed

​

Best Practices

1. Retry Strategy

   • Implement exponential backoff between retries
   • Track retry attempt count
   • Consider time of day for retries
   • Monitor success rates by failure reason

2. Error Handling

   • Log all retry attempts
   • Track retry outcomes
   • Handle webhook notifications
   • Monitor retry limits

3. User Communication

   • Notify users of retry status
   • Provide clear error messages
   • Suggest alternative actions for non-retriable failures
   • Set expectations for processing time