Rate limited resolution

Questions
1

what’s the best resolution to fix rate limited?

  1. retry after some seconds;
  2. use async function in sdk.
    is the second choice async function useful?
    thanks
2

Square does have rate limits but we don’t document the limits. We encourage you to handle the limit gracefully by building a retry mechanism. This mechanism should have an exponential backoff schedule to reduce requests when volume is necessary. Also some randomness wouldn’t hurt to avoid a thundering herd effect. :slightly_smiling_face:

3

Is there a reason this object won’t work in JS/TS if passed under httpClientOptions: { retryConfig }

const SQUARE_RETRY_CONFIG: RetryConfiguration = {
  maxNumberOfRetries: 5,
  retryOnTimeout: true,
  retryInterval: 1,
  maximumRetryWaitTime: 0,
  backoffFactor: 3,
  httpStatusCodesToRetry: [408, 413, 429, 500, 502, 503, 504, 521, 522, 524],
  httpMethodsToRetry: ['GET', 'DELETE', 'HEAD', 'OPTIONS', 'POST', 'PUT', 'PATCH', 'LINK', 'UNLINK']
};

It seems there’s exp backoff support as part of the code shipped by the square NPM package?

4

@Bryan-Square specifically is your package built with “UserConfigurableRetries”: true per Timeout & Retries | Code Generation Settings | APIMatic Documentation

5

That’s with our SDK, right? If so there is exponential backoff support built into the SDK. :slightly_smiling_face:

6

@Bryan-Square it is, however it didn’t end up re-trying anything during that nasty September outage. Can you confirm it should work and your package is built with the UserConfigurableRetries flat set to “true”?

7

It will do retry’s if your using the SDK. Also nothing would have gone through or retried during the September outage. That was a DNS issue. :slightly_smiling_face: