LMEX API Rate Limits and Best Practices for High-Frequency Bots

Every trader who scales up a bot eventually meets the same wall: a burst of 429 responses, orders that never confirm, and a strategy that silently stops working at the worst moment. Rate limits are not an obstacle the exchange puts in your way to annoy you. They are a shared-resource constraint, and a bot that respects them is more reliable than one that fights them. This is a short, practical guide to staying inside LMEX limits while running a high-frequency workload.

How the limits are structured

LMEX applies rate limits per endpoint category and per account, measured over a rolling window. The important mental model is that reads and writes are budgeted separately, and order placement is the scarcest budget. Market data endpoints are generous. Order and account endpoints are not.

The two mistakes that get bots throttled are polling market data on a tight loop when a WebSocket would do the same job for free, and firing order requests in bursts instead of pacing them. Fix those two things and most rate-limit problems disappear.

Rule one: stream, do not poll

If you are polling the order book or trades over REST every second, you are spending your request budget on data you could get pushed to you for free over WebSocket. Move all live market data to the WebSocket feed and reserve REST for what genuinely needs it, order placement, cancellation, and periodic account reconciliation. Our WebSocket tutorial covers a reconnecting client.

Rule two: pace and batch your writes

Order requests should flow through a rate-limited queue, not fire the instant a signal triggers. A token-bucket limiter smooths bursts into a steady stream that stays under the cap.

import time
from collections import deque

class RateLimiter:
    def __init__(self, max_calls, per_seconds):
        self.max_calls = max_calls
        self.per = per_seconds
        self.calls = deque()

    def acquire(self):
        now = time.monotonic()
        while self.calls and self.calls[0] <= now - self.per:
            self.calls.popleft()
        if len(self.calls) >= self.max_calls:
            sleep_for = self.per - (now - self.calls[0])
            time.sleep(max(0, sleep_for))
        self.calls.append(time.monotonic())

limiter = RateLimiter(max_calls=25, per_seconds=1)

def place_order(client, **kwargs):
    limiter.acquire()
    return client.create_order(**kwargs)

Where the API supports it, batch cancels and amendments into a single request instead of one call per order. One batch cancel of ten orders costs far less budget than ten individual cancels.

Rule three: back off, do not hammer

When you do hit a 429, the wrong response is to retry immediately, which digs the hole deeper. Exponential backoff with jitter lets the window clear before you try again.

import time, random

def with_backoff(fn, *args, max_retries=5, **kwargs):
    for attempt in range(max_retries):
        try:
            return fn(*args, **kwargs)
        except RateLimitError:
            wait = (2 ** attempt) + random.random()
            time.sleep(wait)
    raise RuntimeError("rate limit: exhausted retries")

Respect the exchange headers too. LMEX returns your remaining budget and reset time on responses. Read them and slow down before you hit zero instead of reacting after you are blocked.

Rule four: fail safe, not silent

The dangerous failure is a bot that gets throttled mid-strategy, drops an exit order, and keeps trading as if the position closed. Every order path needs confirmation and reconciliation. After placing or cancelling, verify the actual state, and on repeated failures, halt new entries and alert rather than trading blind. Our bot monitoring guide covers the alerting side.

Frequently Asked Questions

Q: What is the actual rate limit on LMEX?

The exact numbers are in the current LMEX API documentation and can change, so read them from the docs rather than hardcoding a guess. The practical approach is to read the remaining-budget headers on each response and pace to them, which stays correct even if the limits change.

Q: Do WebSocket subscriptions count against REST limits?

They are budgeted separately from REST request limits. That is exactly why moving market data to WebSocket frees up your REST budget for order operations.

Q: How do I avoid bursts when many signals fire at once?

Route all order calls through a single rate-limited queue as shown above. Signals enqueue orders; the limiter releases them at a safe pace. Never let strategy logic call the order endpoint directly.

Q: Should I run multiple bots on one API key?

Be careful, because they share the same account budget and will throttle each other. If you must, put a shared limiter in front of all of them or use separate subaccounts so their budgets are independent.

Related Articles