What you get

• Spot balances for every HyperCore token, valued in USD from Hyperliquid's own spot market
• Staked HYPE as its own position, covering delegated, undelegated and pending withdrawals
• Full transaction history with no retention cap: spot trades with both legs, transfers between wallets and between spot and perps, staking and unstaking, genesis distributions, lending movements and rewards claims
• Trading and transfer fees reported in the token they were actually charged in

Action required

None. If you match assets by ticker, prefer ticker_address — it carries the HyperEVM contract address, or the HyperCore token id for tokens with no EVM deployment. HyperCore tickers are short and collide with unrelated tokens listed elsewhere.

Hyperliquid data mapping →

What changed

• Connecting previously required the user's Wealthsimple login credentials. Now they authorize on Wealthsimple's page — no shared password.
• The Connect widget runs the OAuth flow automatically — no change on your side.
• Data output is unchanged: crypto balances, positions and transactions.

Action required

None. Existing credential-based connections keep working and sync identically, with no re-authentication required from your users.

Wealthsimple Crypto data mapping →

What changed

• Connecting OKX previously required the user to create an API key, secret and passphrase in their OKX settings and copy all three into Connect. Now they log in on OKX's authorization page and approve read-only access.
• The Connect widget runs the OAuth flow automatically — no change on your side.
• Data output is unchanged: balances, trades, crypto-to-crypto converts, deposits and withdrawals, and OKX Earn staking positions.

Action required

None, and this is backward compatible: existing API-key connections keep working and sync identically. Nothing to re-authenticate, and nothing for your users to do.

Global OKX accounts are covered. OKX US (app.okx.com) is not yet supported.

OKX data mapping →

What changed

• Webhook traffic previously originated from a range of dynamic addresses. It now comes from a fixed set of addresses that are not expected to change.
• Every webhook now includes an x-client-id header containing your client app id, so a receiver handling more than one app can tell them apart without parsing the body.

Action required

Only if you restrict inbound traffic by source IP. Contact us for the current address list and add it to your allowlist — we do not publish the addresses here. We will give advance notice before they ever change.

If you do not filter by source IP, nothing changes for you.

Direct API

POST /accounts and PUT /accounts/:id return it alongside the existing message:

{
  "message": "This connection is already linked to your account.",
  "existing_institution_id": "<id of the already-linked account>"
}

Connect widget

The DUPLICATE_CONNECTION error event now includes it at the top level of the postMessage payload:

{
  event: "ERROR",
  data: {
    type: "DUPLICATE_CONNECTION",
    existing_institution_id: "<id of the already-linked account>",
    error: { /* unchanged */ }
  }
}

Action required

None — this is purely additive and existing 409 handling keeps working. If you want to use it, the field lets you replace a generic error with something like "you already have this account connected", linked to the existing connection.

What changed

• The sign follows from_address: if it matches the connected wallet, amount is negative; in every other case it stays positive.
• Affects Ethereum, BSC, Polygon, Cronos, Fantom, Avalanche, Arbitrum, Base and Optimism.
• Only transactions imported from this point on. Transactions already in the system keep the sign they were stored with.

Action required

If you derive direction from the sign of amount, check that your logic handles negative values on these chains — previously an outgoing transfer could arrive positive.

Because only new transactions are affected, a wallet can hold both conventions either side of this date. If that matters for your reconciliation, contact us and we can reprocess the earlier transactions for an account.

What you get

• Native SUI plus every coin the address holds, each carrying ticker_address — its full Move coin type — alongside its ticker
• One transaction per Sui transaction block, with each coin movement belonging to the address in parts[], so a swap is one transaction rather than several
• Gas in fees[], computed as computation + storage − storage rebate, and the block digest in transaction_hash

Action required

None. Match coins on ticker_address, not ticker: Sui tickers come from on-chain coin metadata and are not unique, so two unrelated coins can publish the same symbol.

Sui data mapping →

What changed

• The native transfer (ETH, BNB, MATIC and so on) stays in the main transaction object.
• Token transfers move to misc.tokenTransfers.
• NFT transfers move to misc.nftTransfers.
• Affects Ethereum, BSC, Polygon, Cronos, Fantom, Avalanche, Arbitrum, Base and Optimism.

{
  "misc": {
    "tokenTransfers": [
      {
        "direction": "send",
        "ticker": "USDT",
        "token_name": "Tether USD",
        "amount": -106707.39014,
        "from_address": "0x<connected wallet>",
        "to_address": "0x<counterparty>",
        "fiat_ticker": "USD",
        "fiat_value": 106682.96961903569,
        "token_address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
        "possible_spam": false,
        "verified_contract": true
      }
    ],
    "nftTransfers": [
      {
        "direction": "send",
        "token_address": "0x<collection contract>",
        "contract_type": "ERC721",
        "amount": 1,
        "from_address": "0x<connected wallet>",
        "to_address": "0x0000000000000000000000000000000000000000",
        "possible_spam": false,
        "verified_collection": false
      }
    ]
  }
}

Action required

If you read token or NFT movements as transactions of their own, read misc.tokenTransfers and misc.nftTransfers instead. Expect fewer transactions for the same wallet — a swap that previously arrived as several rows is now one.

What you get

• Native TON plus every jetton the wallet holds, each carrying ticker_address — the jetton's contract — alongside its ticker
• Transaction history with the TON leg of each message, network fees in TON, and the TON operation in misc.op_name
• Failed on-chain transactions marked with misc.aborted, since they still cost a fee

Action required

None. Two points worth knowing: jetton amounts are not in the transaction feed — a jetton transfer appears as its TON leg, so read jetton holdings from account.balances[]. And match jettons on ticker_address rather than ticker, since jetton tickers come from on-chain metadata and are not unique.

Toncoin data mapping →

What you get

• HBAR and every HTS token the account holds, with USD values
• Transaction history, typed as a deposit or withdrawal from the account's net movement in each asset
• Network fees in HBAR on outgoing transactions, with the Hedera transaction id in misc.origin_id

Action required

None. One point worth knowing: a single on-chain transaction that moves both HBAR and an HTS token arrives as two Vezgo transactions — one per asset — sharing the same transaction_hash. Group on that field if you need the on-chain transaction as a whole.

Hedera data mapping →

What you get

• One wallet, Coinbase Prime Trading Account, valued at the portfolio's total trading balance
• Per-symbol balances with Prime's own USD valuation, typed crypto or cash_equivalent
• Filled orders as trades carrying both legs in parts[], plus the activity feed: deposits and withdrawals — external, internal, sweep and Coinbase-linked — and conversions
• KYC data: the portfolio user's email and name, with the Prime role, entity id and portfolio id under misc

Action required

Prime lists some network-specific assets under a prefixed symbol — ARBUSDC is USDC on Arbitrum — and those arrive verbatim. There is no ticker_address or network field to resolve them, so map those symbols to the underlying asset on your side. Custodial holdings carry no ticker_address at all, so match on ticker for this connector.

Coinbase Prime data mapping →

What you get

• One wallet, Swyftx Trading Account, valued in USD at the total of everything it holds
• Every asset on the account, with its own USD value, named as Swyftx names it
• Fiat holdings typed cash_equivalent and crypto typed crypto, so the two are separable without a symbol list of your own

Action required

Swyftx provides balances only — there is no transaction history. The provider reports features.transactions: 0, so read that before building against /accounts/:id/transactions for this connector: it will return nothing.

What you get

• Spot, Margin, Earn (staking), Funding, Futures, NFTs and Auto-Invest wallets
• Real-time updates for spot wallets
• Historical orders data

Action required

None, but expect more: a Binance connection will return more accounts, positions and transactions than it did before. If you present accounts individually, check that the new wallet types appear sensibly in your UI.

Action required

None, but note a hard limit we cannot work around: OKX's API exposes only the last three months of trades. Older trades cannot be retrieved, so an OKX account's balances will not be fully explained by its trade history.

What you get

• Balances, positions and transaction history, including XLM and issued assets

Action required

None.

What you get

• Read-only access to holdings and transaction history straight from the device
• No hunting through device settings for a public address to paste

Action required

None. Private keys never leave the device.

What you get

• Balances, positions and transaction history

Action required

None.

Action required

None. A Binance connection with Auto-Invest plans will return more accounts and transactions than it did before.

Action required

None by default. This is opt-in — get in touch for access. See the Real-time data and Order sections of the API documentation.

Action required

None.