Rate limits - Moneyline

The API allows 1000 requests per 60 seconds per API key. Exceeding it returns 429 with a rate_limit_error.

{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Retry after 12 seconds.",
    "request_id": "req_abc123"
  }
}

Handling 429

All three SDKs retry 429 automatically, up to three times, with exponential backoff. For most workloads you do not need to write any handling at all. If you are managing retries yourself, back off exponentially with jitter rather than retrying on a fixed interval — a fleet of workers retrying in lockstep will simply re-collide.

// Raise the retry budget for a bulk backfill.
const client = new Moneyline({ maxRetries: 6 });

client = Moneyline(max_retries=6)

client, err := moneyline.NewClient("", moneyline.WithMaxRetries(6))

Staying under the limit

The most effective lever is usually not concurrency control but avoiding the requests entirely:

Use webhooks instead of polling. A worker polling submission.status every second burns the budget for one deal. Subscribing to submission.processed costs nothing. See webhooks.
Raise limit on list calls. One request at limit=100 does the work of four at the default 25. See pagination.
Batch transaction writes. POST /v1/transactions accepts an array.

Limits are per key, so a separate key for a bulk backfill keeps it from starving your production traffic.