If you write trading bots in Python or JavaScript, you have probably used CCXT. It is the library that turns "fetch the ticker" into one line of code regardless of which exchange you are talking to. As of this week, LMEX is on the supported list.
We forked the main CCXT repo, added LMEX support, ran it against the test suite, and pushed the result back. The fork lives at github.com/LMEXofficial/ccxt. A PR to merge it into upstream CCXT is open. Until that merges (PRs to the main repo can take weeks because they review every exchange addition carefully), use our fork directly.
For anyone running a bot on another exchange, this is probably the simplest "try LMEX" path that has ever existed.
Honest answer: nothing capability-wise. Everything CCXT does, you could already do by calling api.lmex.io directly. The REST API was always there.
What changes is the effort.
Before this integration, hooking up a new bot to LMEX meant writing a client class, handling HMAC signatures, managing rate limits, normalizing the response shapes, and dealing with quirks like the difference between \`last\` and \`lastPrice\` field names that always seem to bite somebody on the first day. Three hundred lines of glue code, easy.
After: \`pip install ccxt\`, then \`exchange = ccxt.lmex({...})\`. Done.
For people building bots, that is hours saved on every project. For people running ready-made bots (Freqtrade, Hummingbot, etc.), it means LMEX is now a one-config-change option instead of a "wait for someone to write the connector" option.
No API key required for public data:
\`\`\`python
import ccxt
lmex = ccxt.lmex()
print(lmex.fetch_ticker('BTC-PERP')['last'])
\`\`\`
If that prints a number, the connection works. If you get a 404 or import error, either you are on an old CCXT version or you have not installed our fork yet.
To do anything authenticated, add credentials:
\`\`\`python
lmex = ccxt.lmex({
'apiKey': 'your-key',
'secret': 'your-secret',
})
print(lmex.fetch_balance())
\`\`\`
Strong recommendation: when you generate the LMEX API key, leave Trading unchecked for the first day. Watch your bot run with Read-only permissions, verify it does what you expect, then come back and enable Trading. This is paranoid but trading bots are exactly where paranoia pays.
Standard CCXT methods all work as expected: \`fetch_ticker\`, \`fetch_order_book\`, \`fetch_ohlcv\`, \`fetch_balance\`, \`fetch_positions\`, \`create_order\`, \`cancel_order\`, \`fetch_open_orders\`, \`fetch_my_trades\`, \`fetch_funding_rate\`, \`fetch_funding_history\`. If a method exists in CCXT, it almost certainly works on LMEX.
A few things we want to be upfront about:
**WebSocket support is REST-polled in free CCXT.** If you want tick-level data, you need CCXT.pro (paid) or our native WebSocket API. For anything operating on a 1-second-or-slower loop this does not matter.
**Some advanced order types are not exposed through the unified interface.** Specifically certain conditional orders and post-only-after-N-seconds. You can still hit them via \`exchange.private_post_orderspecial\` style calls — CCXT just does not have a clean abstraction yet.
**Margin mode switching is eventual.** The API call to change margin mode returns quickly but the change takes a moment to propagate. If your bot switches mode and immediately places an order, sometimes the order is placed under the old mode. We have it filed as a known issue.
This is the use case we are most excited about. Freqtrade reads its exchange support from CCXT, so as soon as you install our CCXT fork in Freqtrade's virtualenv, LMEX appears in the supported exchange list.
The config change is literally this:
\`\`\`json
{
"exchange": {
"name": "lmex",
"key": "your-key",
"secret": "your-secret"
}
}
\`\`\`
Your strategy file, your pair list, your indicators, your risk parameters — all unchanged. Run dry-run mode for a couple of days first to verify the bot's behaviour matches what you saw on the previous exchange. The strategy will produce slightly different results because order book microstructure varies between venues, but the broad shape should be the same.
Hummingbot users follow an identical pattern through their connector config. Jesse needs a small additional step (they handle exchange registration slightly differently from Freqtrade) but it is documented in their CCXT integration notes.
If you are seriously thinking about moving a bot from another exchange to LMEX, here is what we would do, in order:
1. Generate a Read-only API key on LMEX. Skip Trading for now.
2. Point your bot at LMEX with that key. Run it.
3. Watch for at least 24 hours. Verify symbols resolve (LMEX uses \`BTC-PERP\`, your bot might be configured for \`BTC/USDT\` — CCXT handles most of this, but always check). Verify the prices and order book data look correct.
4. Generate a second key with Trading enabled. Cap the maximum order size at something tiny — \$100 or whatever your smallest comfortable amount is.
5. Run live for a few hours with the small-cap key. Verify orders fill where you expect.
6. Increase the cap.
This is slower than necessary for most people, but bot migrations are exactly the place where the cost of moving fast is large and the benefit of moving fast is zero.
Q: Do I install your fork specifically, or wait for the main CCXT release?
Use the fork for now. The PR to merge LMEX into upstream CCXT is open but those reviews take weeks. The fork is identical to upstream CCXT except for the LMEX exchange class — there is nothing weird in it.
Q: How fast is CCXT compared to calling your REST API directly?
A bit slower because of the parsing and unification overhead. For most strategies (anything operating per-second or slower) the difference is invisible. If you genuinely need every millisecond, use our native REST endpoints or FIX 4.2 — but you already knew that if you are asking the question.
Q: Does this work with futures funding rates?
Yes. \`fetch_funding_rate('BTC-PERP')\` returns the current rate. \`fetch_funding_history\` returns historical funding payments and paginates correctly. The format matches the CCXT funding rate spec, so any code you have that consumes funding rates from other exchanges works without changes.
Q: Can I use one API key with CCXT and another tool simultaneously?
Yes. The same key works with CCXT, direct REST, FIX 4.2, and the LMEX MCP server simultaneously. Rate limits are per-key, so if you run too many bots through one key you can hit limits — generate separate keys for separate bots if you are running many in parallel.