Skip to main content

Retry

In this section, we list the scenarios on which client should retry the request and also the retry techniques to use.

  1. Client should only retry for the error scenarios for which ‘Retry’ column says ‘Yes’ in the Error Specifications table.

  2. The retry should be done with exponential backoff.

  3. How long should I retry?

    • The duration of retry will depend on the client use case. If the call flow is part of “live customer experience” (it means that customer is waiting on the response) then the retry window should not be more than few seconds. Please apply your judgement based on your customer experience. The retry window should ideally have maximum 3 retries with exponential backoff.
    • If the call flow is part of a backend logic and doesn’t impact customer experience directly then the client can go with larger retry window. Any unavailability issue at Prime APIs will be fixed in 24 hours. So a retry window spanning one day is more than sufficient to ride over the unavailability issues.

  4. How many times should I retry?

    • A longer retry window doesn’t mean that client should aggressively retry. For example, if the retry window for backend logic is one day then client should not retry every hour. This behaviour will have negative impact for client (client might get throttled) and Prime (In case of major unavailability, it makes the problem more severe at Prime end which might trigger Prime team to do load shedding).
    • Even for a backend login extending 24 hours, we don’t recommend more than single digit retries (ex: 5-6) with suitable exponential backoff.