Skip to main content

Retry Strategy Guideline

Retry Strategies​

These strategies are appropriate to implement in cases like receiving 5xx status code from server and system is under maintenance and end date of maintanance is not specified.

When implementing retry logic in your application, it is important to have a clear retry strategy in place.

A retry strategy defines how and when to retry a request after an error. Here are some common strategies for retrying requests:

  • Fixed delay retry: In this strategy, the same amount of time is waited between each retry attempt. For example, you could wait 1 second between each retry attempt. This is the simplest retry strategy, but it can be less effective if the error is not transient and the delay is not long enough to allow the issue to be resolved.
  • Incremental delay retry: In this strategy, the amount of time waited between retry attempts is increased with each retry. For example, you could start by waiting 1 second, then 2 seconds, then 3 seconds, and so on. This strategy can be more effective at allowing temporary errors to be resolved in case they are not transient.
  • Exponential backoff retry: In this strategy, the amount of time waited between retry attempts is increased exponentially with each retry. For example, you could start by waiting 1 second, then 2 seconds, then 4 seconds, then 8 seconds, and so on. This strategy is similar to incremental delay, but the increase in delay is exponential rather than linear. This strategy can be more effective at allowing temporary errors to be resolved in case they are not transient.
info

There are pros and cons to Incremental Delay Retry and Exponential Back-off Retry strategies.

Incremental delay retry is simpler to implement and may be more predictable, but it may not be as effective at handling temporary failures.

Exponential backoff retry is more complex to implement, but it may be more effective at handling temporary failures because the delays between retries increase over time, giving the system more time to recover.

Overall, the choice of which retry strategy to use depends on the specific needs of the system and the type of failures that are being encountered. In some cases, a combination of both strategies may be used to achieve the desired level of reliability.

You can choose the retry strategy that best fits your needs, or you can implement a custom retry strategy that combines different strategies.

Retrying safely​

  • Orders: always send your own newOrderClientId (up to 50 characters). If a request times out, send it again with the same newOrderClientId. If the first one was placed, you receive DUPLICATE_CLIENT_ORDER_ID (1246) with the existing order's id in data, and no second order is created. If data.id is null, the result of the first request is not known yet: find the order by orderClientId in Open Orders or All Orders before sending a new order with a different newOrderClientId.
  • Withdrawals: always send your own uniqueTransactionId and reuse it when retrying.
  • Cancels: cancelling an order that is already cancelled returns 200 SUCCESS, so cancels can be retried.
info

To prevent multiple insertions when inserting a new resource, we recommend checking that the resource does not already exist on the server before making a POST request. You can use GET endpoints to verify the existence of the resource before attempting to insert it.

Rate Limits ​

If you receive a response with a status code of 429 (Too Many Requests), it means that you have exceeded the rate limit for the endpoint you are trying to access. In this case, you will need to wait for a certain amount of time before making a new request.

This time is indicated in the Retry-After header of the response. For example, a Retry-After value of 52 means that you need to wait 52 seconds before making a new request.

It is important to implement proper retry logic in your application to handle these rate-limit errors. Here are some best practices to follow when implementing retry logic:

  • Always check for a Retry-After header in the response if you receive a status code 429, before retrying a request.
    • If the Retry-After header is present, wait for the amount of time indicated in the header before retrying the request. Do not retry the request immediately, because you will keep getting 429 responses until a specified amount of time in the header passes.
    • If the header is not present, you can implement one of the retry strategies described above.

You can get information about our rate limits by visiting; Rate Limits