WEEX API Compatibility: What Changes When You Migrate From Another Exchange

If you have already written integration code for Binance, OKX, or Bitget, the only thing you really want to know about WEEX is this: what can you reuse, and what must you rewrite? Rather than list endpoints, this piece looks at WEEX API compatibility across three axes — authentication style, the ccxt unified layer, and spot/contract versioning — and ends with a decision checklist for what to touch when you migrate. The weight stays on the two things that break in practice: how you call it, and how you handle permissions and keys.

The headline up front: WEEX's authentication design belongs to the OKX / Bitget family (Base64-encoded HMAC pre-sign plus a passphrase), not the Binance "query-string signature" style. Grasp that one fact and you can estimate the migration effort accurately.

What "WEEX API Compatibility" Actually Refers To

"Compatibility" here has three layers — don't conflate them:

• Auth compatibility — whether the signing algorithm, headers, and timestamp format match the exchange you know, which decides if your signing module needs a rewrite.
• Abstraction compatibility — whether a unified library like ccxt lets one codebase run across venues.
• Internal version compatibility — whether WEEX's spot vs contract, and V2 vs V3, share fields and paths, which decides your effort when crossing products inside WEEX.

Figure out which layer you're migrating, then read the comparisons below.

Auth Compatibility: WEEX vs Binance vs OKX Style

This is the hardest part of any migration. Per its signature docs, WEEX builds a pre-sign string of timestamp + method + path + body, runs HMAC SHA256, Base64-encodes the output, and passes it through four ACCESS-* headers. The table sets the three mainstream styles side by side (WEEX data from official docs, as of July 2026; the others are each exchange's widely documented public conventions):

The read: migrating from OKX or Bitget to WEEX, the signing logic is nearly copy-paste — you mostly rename headers. Migrating from Binance means rewriting the signing module — Binance signs query parameters, outputs hex, and has no passphrase, a completely different model from WEEX's Base64 pre-sign. WEEX using a millisecond timestamp, meanwhile, is closer to Binance than to OKX's ISO format, and that kind of detail is the easiest thing to miss in a migration.

Can ccxt Make WEEX Compatible Out of the Box?

Yes — and it is the least painful way to sidestep the auth differences. The open-source library ccxt already includes WEEX, covering spot, contracts (swap), and WebSocket across 80-plus unified methods. If you already run ccxt against another venue, moving to WEEX is basically a class name and three credential fields:

import ccxt

ex = ccxt.weex({
    "apiKey": "your-APIKey",
    "secret": "your-SecretKey",
    "password": "your-Passphrase",   # WEEX passphrase → ccxt "password"
})
print(ex.fetch_ticker("BTC/USDT"))

fetch_ticker, fetch_balance, and create_order are identical across venues, so the business layer barely changes. The caveat is that ccxt is a community abstraction: symbol naming (BTC/USDT vs BTCUSDT), precision, and fee fields are normalized by ccxt, but if WEEX ships a new endpoint, ccxt coverage can lag — verify against the WEEX API introduction when chasing new features.

Spot and Contract Version Compatibility (V2 / V3 BETA)

There is a compatibility question inside WEEX too, when you cross products. Spot and contract APIs are both on V3 (BETA), with contracts also keeping V2. Two conclusions follow:

• Spot and contracts share the same ACCESS-* auth and HMAC SHA256 + Base64 signing, so the auth module is reusable across both product lines — only paths and business fields differ.
• Contracts running V2 alongside V3 means legacy code may sit on V2. Because V3 is still labeled BETA, confirm the version you depend on before a production launch and subscribe to the changelog so a shifting BETA field doesn't blindside you.

In one line: WEEX's internal auth compatibility is strong; what you need to watch is the "BETA" status and the version-migration cadence.

What Code You Change Migrating to WEEX

Broken into an actionable checklist, effort varies sharply by source:

Whatever the source, three WEEX-specific settings must be honored: a timestamp more than 30 seconds off the server is rejected; public endpoints allow roughly 20 requests per 2 seconds and return HTTP 429 on excess; the general rules live in the standard specifications doc.

Is the Compatibility Layer Safe? Permission and Key Migration Notes

The thing most often "forgotten" in a cross-exchange migration is the security config — the loose habits from an old venue become a liability the moment they land on a new key. Whether WEEX supports API trading, and its official security guidance, is covered in the WEEX API trading explainer. During migration, verify:

• Re-minimize permissions — WEEX keys default to Read Only, and trade access is manual; don't open everything for convenience, and don't carry over an old venue's "full access" habit.
• Re-bind the IP whitelist — after switching server egress IPs, rebind; WEEX explicitly flags keys with no IP binding as a risk.
• Passphrase is a new field — teams migrating from Binance routinely forget WEEX requires a passphrase that cannot be recovered if lost; fold it into your secrets flow.
• No withdrawal permission by default — this limits stolen-key damage, but it is no reason to relax SecretKey handling.

The Bottom Line

WEEX API compatibility comes down to one sentence: auth belongs to the OKX / Bitget family, ccxt papers over the differences, and spot and contracts share one signing scheme internally. Migrating in from ccxt or a same-family exchange is nearly painless; from Binance it is mainly a signing rewrite plus adding a passphrase. The real extra investment is not the integration — it is re-doing the security config (least privilege, IP whitelist, passphrase management) in the new environment. To start the comparison hands-on, work from the WEEX API introduction.

Further reading: ccxt's WEEX method coverage is in its official wiki.

FAQ

1. Is the WEEX API compatible with the Binance API?

Not at the signing level. Binance signs a query string, outputs hex, and uses no passphrase; WEEX pre-signs timestamp + method + path + body, outputs Base64 after HMAC SHA256, and requires a passphrase. Migrating from Binance means rewriting the signing module.

2. Is the WEEX API compatible with OKX or Bitget?

Very close. All three use the Base64 pre-sign + passphrase style with ACCESS-* headers, so signing logic is largely reusable. The main difference is that OKX uses an ISO-8601 timestamp while WEEX uses a millisecond epoch.

3. Can ccxt connect to WEEX and other exchanges at once?

Yes. ccxt already includes WEEX (spot, contracts, WebSocket), and the same fetch_ticker, create_order, and similar methods work across venues — switching exchanges only changes the instantiated class and credentials.

4. Can WEEX spot and contracts share one auth codebase?

Yes. Both product lines use the same ACCESS-* headers and HMAC SHA256 + Base64 signing, so the auth module is reusable; only the request paths and business fields differ. Both are on V3 (BETA), with contracts also on V2.

5. What security item is most often missed when migrating to WEEX?

Three: failing to re-bind the IP whitelist; missing the passphrase when coming from a no-passphrase venue like Binance; and carrying over a "full access" key. WEEX keys default to read-only with no withdrawal permission, so re-scope to least privilege accordingly.

Risk Warning

Digital assets are highly volatile, and automated or cross-exchange trading via API can lose part or all of your capital through strategy flaws, sharp market moves, or system failures. Migration and multi-venue setups add specific risks: a signing or timestamp misconfiguration can cause failed or duplicate orders; a leaked key with no IP binding can let an attacker act on your account; relying on a third-party abstraction like ccxt means its field mapping or version lag may diverge from the exchange's actual behavior; and contract leverage amplifies losses. Apply least-privilege permissions, re-configure IP whitelist and passphrase per venue, and validate compatibility with small size before production. This article is a technical comparison and is not investment advice.