Rate limited resolution

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?

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:

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?

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

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

@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”?

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: