Install and activate

Licensing the XT provider, putting the API credentials in .env, switching the platform onto XT, and running the two imports that must happen before anyone can trade.

5 min readUpdated 3 August 2026install, license, env, activation

There is nothing to unzip. The XT provider is already a row in your database — the exchange seeder inserts Binance, KuCoin and XT on every install, whether you own them or not:

{
  name: "xt",
  title: "XT",
  productId: "54510301",
  link: "https://mashdiv.com/products/xt-provider",
  type: "spot",
}

What you are buying is the licence that unlocks it. Installing therefore means four things: activate the licence, supply credentials, switch the platform onto XT, and import the currencies and markets XT lists.

Enabling XT disables whichever provider is currently active, and the currency and market imports rewrite tables that the previous provider populated. On a live install with SPOT balances, read the switching warning on the overview first.

Before you start

An XT account with API access, and a key created with the permissions listed in API keys and network access.
The server's public IPv4 address, whitelisted on that key.
Your Envato purchase code and Envato username for item 54510301.
Shell access to edit .env and restart the backend. Every step below that touches credentials needs a restart, and no button in the admin panel performs one.

Install

Activate the licence — Admin → System → Extensions, filter to Exchanges, open XT. Enter your purchase code and Envato username.

Activation calls out to the licence server and, on success, writes an encrypted, machine-bound lic/54510301.lic. That file is the gate: the status endpoint refuses to enable a provider whose .lic is missing and answers 403 with licenseRequired: true.

If you downloaded the Envato licence file instead, drop it in /lic and use the activate-from-file path — it reads the purchase code out of the file for you.
Add the API credentials to .env — the backend reads them by name, derived from the provider's name column (xt), uppercased:
```
APP_XT_API_KEY="your_xt_api_key"
APP_XT_API_SECRET="your_xt_api_secret"
```
XT declares apiKey and secret as its only required credentials. There is no passphrase — APP_XT_API_PASSPHRASE is loaded by the shared code path but XT ignores it.
Restart the backend — credentials are read from process.env when the exchange instance is first created, and that instance is then cached for the life of the process. An edit without a restart has no effect.
```
pnpm stop && pnpm start
```
Enable XT — back on Admin → System → Extensions → Exchanges, toggle XT on.

The status endpoint sets status = false on every other exchange row inside the same transaction. Binance and KuCoin are now off, whatever their licence state.
Verify the connection — go to Admin → Finance → Exchange and press Verify Credentials.

The check is not cosmetic. It builds a throwaway instance, synchronises the clock against XT, calls loadMarkets() and then fetchBalance() — an authenticated endpoint. Only a successful balance read reports valid.
Import currencies — Admin → Finance → Currency → Spot → Import.

This pulls XT's currency list with its per-network deposit and withdrawal data. Run it as a preview first; it reports what it would create, update and delete before writing anything.
Import markets — Admin → Finance → Exchange → Markets → Import.

Same preview-then-confirm shape. It writes each symbol's precision, limits and XT's maker/taker rates into exchange_market.
Enable the markets you want to list — imported markets arrive disabled. Enable a handful and check /market and /trade?symbol=BTC-USDT.

What "verified" does and does not prove

The verification button answers one question: does XT accept this key for an authenticated read, from this server, right now. It says nothing about whether the key can trade or withdraw — those permissions fail later, at the moment a customer needs them.

Read the failure messages literally, because they are distinct:

Message	Cause
`API credentials are missing from environment variables`	`APP_XT_API_KEY` or `APP_XT_API_SECRET` is empty, or the backend has not restarted since you set them
`Invalid API credentials. Please check your API key and secret.`	XT rejected the signature — wrong key, wrong secret, or the key was deleted
`Access denied: Your server's location is blocked by this exchange…`	HTTP 451. XT geo-blocks the server. Configure a proxy
`Server time synchronization failed…`	The clock drifted far enough that signed requests fall outside the receive window
`Rate limit exceeded. Please wait a moment and try again.`	You are being throttled; the ban switch may now be set

The silent failure to know about

If loadMarkets() fails for a reason that is neither a rate limit nor a timestamp error, the manager does not give up. It closes the authenticated instance and replaces it with an unauthenticated one, so that public, read-only endpoints keep working:

Falling back to an unauthenticated xt instance — authenticated data
(deposit/withdraw networks, balances) will be unavailable until valid
API credentials are configured.

That is a deliberate trade: charts and tickers survive a credential problem. The consequence is that the platform can look completely healthy on the front page while deposit-address generation, balance reads and withdrawals all fail. If customers report "no deposit address" and the trade page is fine, search the backend log for that line before anything else.

Post-install checklist

Uninstalling or switching away

Toggling XT off leaves everything else in place: currencies, markets, orders and SPOT wallet rows all stay. The platform simply has no active provider, and the admin exchange page shows No active exchange provider.

That is the correct state to be in while you re-import for a different provider, but do not leave it there with customer balances outstanding. With no provider active, startExchange() returns null, so orders return 503, deposits are never verified, withdrawals cannot be initiated and prices stop updating.