Your Bot Runs on CCXT: What to Recheck Before Moving It to Another Exchange
CCXT is a layer of open-source code between a trading bot and each exchange's API. When the bot wants to place an order, check a balance or pull candles, it says so once in CCXT's common vocabulary. CCXT turns that into the request format of the exchange on the other end and sends it, then tidies the response into one standard shape before handing it back.
So when a bot says it runs on CCXT, very little has to change on the program's side when it connects to a new platform. None of the platform's own rules go away, though. The minimum order size, how many decimal places price and amount can have, which order types are supported and how many requests you can send per second still vary from one exchange to the next, and those are what you need to look at again before you switch.
CCXT is the translation layer between your bot and the exchange
An API is the interface an exchange opens up for programs: they use it to send instructions and fetch data. Every exchange's API looks different, with different addresses, different parameter names and a different layout for the data it returns. CCXT's README describes the project as a cryptocurrency trading API library connecting to more than 100 exchanges. The uses it lists are storing market data, analysis, backtesting strategies and writing bots, and it is aimed at developers, technically skilled traders and data analysts. If you use an off-the-shelf bot, you never touch CCXT itself; you use it through the bot.
Its structure is laid out in the first few paragraphs of the online Manual. Each exchange in the library has its own "class", which you can think of as a phrasebook written for that one exchange, implementing its public and private APIs. All the classes are built on the same base class and share one set of methods. The public API fetches market data and needs no authentication. The private API is for trading and reading account data, and it does need authentication: that is the part where a bot asks you for API keys (the pair of keys a platform issues for programs to use).
Besides translating, it leaves a direct route open. Every native endpoint of every exchange has a matching "implicit method" in the library: the parameters go through unchanged, and what comes back is the exchange's own raw response, with no tidying. The Manual recommends using the unified methods first and keeping implicit methods for cases the unified ones don't cover yet. If a bot feature works on only a handful of platforms, one possible reason is that it takes this route.
Orders, balances and candles: what keeps the same name on every exchange
Method names and parameter order are fixed. The latest price is fetchTicker, the order book (the queues of resting buy and sell orders) is fetchOrderBook, candles are fetchOHLCV, the balance is fetchBalance, placing an order is createOrder, cancelling one is cancelOrder, and your own fills are fetchMyTrades. The order method always takes its parameters in the same sequence: symbol, order type, side, amount, price, extra params. The bot's author writes the order logic once, and that one line serves every exchange it connects to.
Trading pairs are written the same way throughout the library, in upper-case letters with a slash in the middle, like BTC/USDT. Internally each exchange has its own identifier for the same pair, called the market id, and that is what goes into the actual request. If a bot's settings ask you to type something like BTC/USDT, you are typing the library's unified form. Where exchanges disagree on a coin's ticker, the library swaps it using known mappings, such as replacing XBT with BTC.
When something goes wrong, each exchange reports its own error codes and messages. CCXT sorts them into a fixed tree of error classes, and names like NetworkError and InvalidOrder in a bot's log are nodes on that tree.
Minimum order size, precision, order types and rate limits are still set by each exchange
This layer makes sure the request is phrased the same way everywhere. Whether the exchange accepts it, and down to what level of detail, is out of its hands. The Manual has a few terms for exactly this part, and they turn up in bot documentation and error messages too.
has (the capability table). Each exchange class carries a table that marks, method by method, where each unified method stands on that exchange. true means the exchange has the endpoint natively and the library has unified it; false means the exchange's API simply doesn't have it; emulated means the exchange doesn't have it and the library builds a result from other endpoints; an empty value means the library hasn't implemented it yet. The major exchanges also have a features table listing, by market type such as spot or futures, which methods and features are supported. If a feature can be switched on with one platform and is greyed out on another, this table is a good first place to look.
params (extra parameters). Most unified methods end with an optional slot for extra parameters, used for settings specific to that exchange; what can go in it is set out in that exchange's own API docs. One exchange won't accept another's extra params, so they can't be swapped. According to CCXT's FAQ page, advanced order options such as reduce-only, take-profit and stop-loss, and trailing orders are all passed through this slot. The same page points out a difference that trips people up: for a spot market buy, many exchanges want the "amount" to be how much of the quote currency you spend (how many USDT, say), and won't accept the number of coins you want to buy.
precision and limits. precision governs how finely price and amount can be written; limits sets the minimum and maximum for a single order's amount, price and cost. The two are easy to mix up. A minimum order amount of 0.05 and an amount precision of 0.0001 can both apply at once: the first decides whether you can place the order at all, the second how many decimal places you can write. The library reads these values for every pair and stores them in the market information, but it doesn't police them for you; staying within every limit and precision is the user's job. For someone using a ready-made bot, the "user" is first of all the bot's author. Whether they round the numbers for you and compare against the minimum before ordering is something to check in the bot's own documentation.
rateLimit (request spacing). The library has a built-in rate limiter, on by default, that spaces out consecutive requests in the background; it is still marked experimental. Its default interval is on the conservative side, and the allowance each exchange actually gives differs. Each instance has its own limiter (every object your program creates to connect to an exchange is an instance), and one instance doesn't know how many requests another has sent.
| Item | How far CCXT goes | What you check yourself |
|---|---|---|
| Names for placing orders, cancelling and checking balances | Unified | Nothing to check |
| Trading pair format | Unified into the slash form | Whether the new platform lists the pair, and whether it is open for trading now |
| Order types and extra params | Only the entry point is unified; the contents differ by exchange | Whether the order types your strategy uses are supported on the new platform |
| Minimum order amount and cost | Can read the values; doesn't enforce them for you | Whether the smallest order in your strategy is above the minimum |
| Price and amount precision | Can read the values; doesn't enforce them for you | After rounding to the new precision, how much each order's amount and price spacing have changed |
| Fees | Market information has two fee fields, taker and maker; the values differ by exchange | Recompute per-trade profit at the new rates |
| Request rate | Built-in rate limiter; allowances differ by exchange | Your polling interval (how often the program asks for prices), and whether any other program is sending requests on the same account |
| Market data speed | Not handled | How often the new platform updates its market data |
Taker means your order fills straight against orders already resting on the book; maker means your order rests on the book first and waits for someone else to fill it. The two rates are separate fields in the market information. The definitions and error groupings in this article follow the October 2026 versions of the Manual, FAQ and AI Skills pages on docs.ccxt.com. Fields and defaults may change as the library is updated, so check which version your bot actually has installed.
NetworkError, InvalidOrder, RateLimitExceeded: what each one in your log points to
When troubleshooting, first work out which branch of the tree the error falls on. According to the AI Skills page on CCXT's documentation site, errors on the NetworkError branch are recoverable: wait a moment and retry, and lengthen the wait if the failures continue. The ExchangeError branch is not recoverable, and sending the same request again will fail again.
On the NetworkError branch, RateLimitExceeded means you have hit the request rate limit, so wait before sending again. In the repository's error definitions file (python/ccxt/base/errors.py), the same branch also holds RequestTimeout, ExchangeNotAvailable, OnMaintenance and DDoSProtection, whose names mean, in turn, that the request timed out, the exchange is unavailable, it is under maintenance, and DDoS protection kicked in. An error from this branch means the trouble is on the way there, or the other side is temporarily not taking requests; your strategy parameters haven't been rejected.
On the ExchangeError branch, AuthenticationError means the API credentials are invalid, InsufficientFunds means the balance is too low, and InvalidOrder means the order parameters break the rules. The same branch also has NotSupported and BadSymbol, which mean the feature isn't supported and the pair name is wrong. Resending won't help with any of these. What needs changing is the key, the balance or the order parameters, or you switch to an approach this exchange does support.
What to look at again when the same strategy moves to another exchange
When you switch platforms, the only things to change in the bot's settings may be the platform name and the keys, and the strategy will start with its parameters untouched. The fact that it starts only tells you the names line up.
Open the new platform's trading rules page, or have the bot print the market information for the pair, and write down four numbers: the minimum order amount, the minimum order value, the price's minimum increment and the amount's minimum increment. Compare the smallest order in your strategy against them. Anything below the minimum value will be rejected; if an amount rounds to 0 at the new precision, or ends up noticeably different from before, the size of every entry and exit has changed. Next, look at the taker and maker rates on the fee page, take two fees, one for the buy and one for the sell, off the expected profit per trade, and see what's left. Finally, go through the bot's documentation for the order types it lists as available on the new platform. If the stop orders or reduce-only orders your strategy relies on aren't listed, treat them as unsupported.
Take a grid. Each grid's order size is the total capital divided by the number of grids, so with tightly spaced grids each order is small. On the old platform the minimum was low and the grid ran; move it to a platform with a higher minimum and, with the same number of grids, a batch of orders can't be sent. Retrying won't fix this kind of rejection. You need to lift each grid's order above the minimum, for example by using fewer grids.
Rate limits need another look too. Built-in rate limiters each keep their own count: run two bots on the same account at once, or have a script polling prices alongside the bot, and each one thinks it is within the limit. How the platform adds them up is in its API documentation.
On the market data side, CCXT takes whatever data that platform provides. If the platform updates slowly or aggregates coarsely, that is what reaches the bot. If signals fire at different moments after the switch, start with why prices differ between data sources.
If you are not ready to put real money in and only want to test in simulation mode, you can still check these items first. Market information comes through the public API, so reading it needs no key and no deposit on the platform.
Further reading: if the bot stops placing orders or starts throwing errors after the move, Trading Bot Not Placing Orders or Throwing Errors? goes through nine common faults and what to check first.