Akahu's APIs enforce a combination of global rate limiting and endpoint-specific rate limits.

If your request is rate limited, Akahu will respond with an HTTP status code of 429 "Too Many Requests". If your app receives a response from Akahu with a 429 status code, the request should be retried after a short delay. We recommend using an exponential backoff retry strategy.

Here is an example delay calculation for an exponential backoff strategy. This example also includes random jitter to avoid the thundering herd problem.

/**
 * This is the initial/base delay (ms) for the exponential backoff strategy.
 *
 * A base of 100ms will generate following sequence of delays (before random
 * jitter is applied):
 *
 * 100ms, 200ms, 400ms, 800ms, 1600ms, 3200ms, 6400ms etc...
 */
const RETRY_BACKOFF_BASE = 100;

/**
 * Calculate the next delay (milliseconds) of an exponential backoff strategy.
 *
 * Applies a random jitter to each delay to avoid the "thundering herd" problem
 * caused by multiple clients retrying concurrently.
 */
function getRetryDelayMs(retryCount: number) {
  // Random jitter factor between 0.75 and 1.25;
  const jitter = 0.75 + Math.random() / 2;
  // Exponential backoff with jitter applied.
  return (RETRY_BACKOFF_BASE * 2 ** retryCount) * jitter;
}

Endpoint specific limits

Currently the only endpoints which have specific rate limits in addition to global rate limiting are POST /v1/payments and POST /v1/transfers. Rate limiting for these endpoints is applied on a per-user basis, meaning that your app cannot exceed the specified rate of requests for any individual user. A single quota is shared by both endpoints.

Currently the rate limit for initiating payments and transfers is 200 requests/user/minute.

ℹ️

Note: Akahu reserves the right to update our rate limiting strategy without notice.