Rate Limits

Requests are rate limited per API key and per source IP — whichever limit is reached first applies. Exceeding either returns 429.

The limits

Published as concrete numbers so you can pace a loop rather than discovering the cap as a 429. Each route carries its own counter, so a swap quote does not spend a send quote’s budget. Anything not listed falls back to the default.

Operation	Per minute
`POST /v1/payment-link`	60
`GET /v1/payment-link`	300
`POST /v1/quote/send`	20
`POST /v1/quote/swap`	20
`POST /v1/transaction`	10
`GET /v1/transaction`	300
`GET /v1/transaction/{id}`	300
`GET /v1/token/detail`, `GET /v1/token/price/history`	60
Everything else, including the other `GET`s	300

The quote routes are tight because each one fans out to a paid third-party routing API. The transaction write is tighter still: 10 a minute is 600 an hour, which is far above any real integration and low enough to blunt a runaway loop.

POST /v1/transaction is one shared budget across Send and Swap — it is the same endpoint for both — so a run that does both has to pace against the pair, not against each separately. There is no batch endpoint: a batch payout is your own loop over quote → sign → record, so sleep between iterations rather than firing them all at once.

Re-quoting before every signature costs a quote each time. You should re-quote: a stale swap quote fails on chain once the market moves past its slippage tolerance, and you still pay the network fee for the attempt. So budget the quote route for one call per transaction rather than one per batch.

Why two limits

A per-key limit protects the account from one runaway integration. A per-IP limit protects the API from a host running many keys.

Sharing one outbound IP across several keys means the IP limit can bite before any individual key’s limit does. If you run multiple integrations from one host, budget against the IP.

Handling 429

{
  "errors": [
    {
      "message": "Too many requests. Please try again later.",
      "code": "429"
    }
  ]
}

The code is the string "429". Branch on the HTTP status. Back off exponentially with jitter, and cap the number of attempts.

async function withRetry<T>(fn: () => Promise<Response>, attempts = 5): Promise<Response> {
  for (let i = 0; i < attempts; i++) {
    const res = await fn();
    if (res.status !== 429 && res.status < 500) return res;
    const delay = 2 ** i * 1000 + Math.random() * 1000;
    await new Promise((r) => setTimeout(r, delay));
  }
  throw new Error('rate limited: retries exhausted');
}

Retrying immediately on 429 makes it worse. Every rejected request still counts.

Staying under the limit

Do not poll for payment status

GET /v1/payment-link and GET /v1/transaction are for reconciliation, not for watching one item. Polling a single id in a tight loop is the fastest way to a 429.Poll on a sensible interval — seconds, not milliseconds — and back off when nothing has changed.

Size your polling from executionDuration

Every quote reports an executionDuration in seconds. A same-chain swap or send settles in seconds; a cross-chain bridge can take minutes.Use that number as your first wait rather than polling from the moment you broadcast. A processing bridge is not a failure — it is a bridge.

Pace a payout or swap run

There is no batch endpoint. A run of 50 payouts is your own loop over POST /v1/transaction, which allows 10 a minute — so sleep between iterations rather than firing them all and collecting 429s.Every rejected request still counts against the limit, so a loop that meets the cap and retries immediately makes itself slower.

Create links on demand, not in advance

A link created when the customer reaches checkout is one request. Pre-generating batches multiplies request volume for links that may never be used.

Use one key per service

Separate keys give each integration its own budget, and let you revoke one without taking down the rest.

Cache what does not change

A created link’s id and url never change. Store them rather than re-reading them.

Errors

Which codes retry.

Pagination

Paging without hammering.

Moove Swap

Quoting, signing and recording.

API Documentation

Moove Receive

Moove Send

Moove Swap

Coming Soon

The limits

Why two limits

Handling 429

Staying under the limit

Next

Errors

Pagination

Moove Swap

​The limits

​Why two limits

​Handling 429

​Staying under the limit

​Next

Errors

Pagination

Moove Swap

The limits

Why two limits

Handling 429

Staying under the limit

Next