# Bit2Me API > Developer documentation for the Bit2Me gateway REST API, Spot Trading API, partner onboarding, WebSockets, and MCP. Server: https://gateway.bit2me.com Status: https://status.bit2me.com Support: https://support.bit2me.com Tickets: https://support.bit2me.com/en/support/tickets/new API keys: https://account.bit2me.com/api-keys MCP: https://mcp.bit2me.com OpenAPI source: https://gateway.bit2me.com/docs/openapi.json plus openapi/overlay.json in this repo, split per product by openapi/products.json Do not invent endpoints, SLAs, sunset dates, or Travel Rule thresholds. Nonce is Unix time in milliseconds. - [Introduction](/docs): Build on the Bit2Me API — wallet, Pro trading, partner onboarding, and MCP. - [Quickstart](/docs/quickstart): Create keys, sign a request, and call the Bit2Me gateway. - **Get started** - [Account model](/docs/guides/account-model): Parent account, subaccount, and pocket hierarchy on the Bit2Me API. - [Authentication](/docs/guides/authentication): HMAC-SHA512, nonce, subaccount header, and TOTP for the Bit2Me gateway. - [Rate limits](/docs/guides/rate-limits): Starter, Medium, and Pro request-per-minute limits for the Bit2Me API. - [Errors](/docs/guides/errors): HTTP statuses you will see on the Bit2Me API and how to react. - **Wallet** - [Buy, sell, and swap](/docs/wallet/buy-sell): Wallet proforma then execute for buy, sell, and pocket-to-pocket moves. - [Changelog](/docs/wallet/changelog): Deprecated Wallet API endpoints and what to use instead. - [Crypto deposits](/docs/wallet/crypto-deposits): Receive crypto from another platform into a parent or subaccount pocket. - [Earn](/docs/wallet/earn): Staking positions, rewards, and movements on the Wallet API. - [Loans](/docs/wallet/loans): Crypto-backed loans: simulate LTV, create an order, increase guarantee, pay back. - [Money flow](/docs/wallet/money-flow): How value moves between Wallet, Pro, Earn, and funding rails. - [Pockets](/docs/wallet/pockets): Create and list currency pockets under a parent or subaccount wallet. - [API overview](/docs/wallet/rest-overview): How to use the generated Wallet OpenAPI reference on this site. - [Notification events](/docs/wallet/websocket-events): Gateway WebSocket types from the public Crypto OpenAPI. - [Gateway notifications](/docs/wallet/websocket): Connect to the gateway WebSocket, authenticate with JWT or API key, and receive wallet, teller, identity, and loan events. - Api reference - Access - [Sign in with API key](/docs/wallet/api-reference/access/v1/signin/apikey/post): Authenticates a user using an API key and returns a JWT access token. The API key must be sent via the `ApiKeyAuth` security scheme. The request body carries the `userId` that the key belongs to. On success the response contains an `accessToken` with its expiration timestamp. - [Sign in with embed token](/docs/wallet/api-reference/access/v1/signin/embed/post): Authenticates a user with an embed access token. Returns a JWT access token, a refresh token, and a session object. When the subaccount's main user has `forceSubaccountSfa` enabled, the caller must supply a TOTP code via the `x-totp` and `x-totp-type` headers. If the code is missing or the main user requires SFA, the gateway returns `428` with the SFA metadata needed to prompt the user; if the code is wrong, `420` is returned. - [Check and start two-factor verification](/docs/wallet/api-reference/access/v3/signin/sfa/get): Checks the active two-factor authentication methods for the authenticated user and initiates the verification process. When `sfaType` is phone-based (`sms`, `call`, `whatsapp`) the service sends the OTP code immediately and returns a `retryIntervalSeconds` countdown. Optionally accepts an `operation` query parameter to scope the 2FA challenge to a specific action (e.g. withdrawal, email change). - Wallet - [List the user's pockets, or get one](/docs/wallet/api-reference/wallet/v1/wallet/pocket/get): Returns the authenticated user's pockets, the wallet accounts that hold one asset each. A user can have several pockets of the same asset. Deleted pockets are not listed. Without `id` every pocket is returned, sorted by balance, highest first. With `id` the response is an array with that single pocket, or `404` when the user has no such pocket. - [Create a pocket](/docs/wallet/api-reference/wallet/v1/wallet/pocket/post): Creates a new, empty pocket of an asset for the user. Any crypto asset can be used; the only fiat currency allowed is `EUR`. The number of pockets is limited, both per asset and per week; reaching either limit answers `406`. The `4xx` bodies other than `400` field validation carry a copy of the whole error in `data`. - [Delete a pocket](/docs/wallet/api-reference/wallet/v1/wallet/pocket/delete): Deletes one of the user's pockets. It must be empty, must not be the user's last pocket of that asset, and must have no active recurring orders. A deleted pocket no longer appears in `GET /v1/wallet/pocket`. - [List the wallet operations allowed per asset](/docs/wallet/api-reference/wallet/v1/wallet/settings/assets/get): Returns, for each asset the wallet supports, the operations it allows: deposits, withdrawals, transfers, buys, sells, swaps and Earn. Use it to decide which actions to offer for an asset: an operation that is not listed for an asset is not available for it. It does not need authentication. - [Quote a wallet operation (create a proforma)](/docs/wallet/api-reference/wallet/v1/wallet/transaction/proforma/post): Prices an operation without executing it and returns a proforma: the exact amounts each side will move, the fees and the rates, valid until `expirationTime`. Execute it with `POST /v1/wallet/transaction`, sending its `id` as `proforma`; an expired proforma cannot be executed and has to be requested again. What the operation is depends on the fields sent: - **Between own pockets** (no `operation`): `pocket` (or `currency`) as source and `destination.pocket` or `destination.currency` as destination. The same asset is a transfer; from fiat to crypto a buy, from crypto to fiat a sell, between two cryptos a swap. Conversions between two fiat currencies are rejected. - **Buy or sell by market** (`operation` `buy` or `sell` with `pair`, and no `pocket` or `destination`): the pockets of both assets are used, and created if the user has none. - **Withdrawal to a blockchain address** (no `operation`): `destination.address` with `destination.network`, and `destination.tag` or `queryParams` on networks that need a memo. - **Withdrawal to a bank account** (no `operation`): `destination.bankAccount` from a fiat pocket. - **Buy with an external payment method** (`operation` `purchase`): `origin` says how to pay and `destination.pocket` or `destination.currency` where the asset goes. - **Social Pay** (`operation` `social-payment`): `pocket` and one of `destination.email`, `destination.phone` or `destination.alias`. - **Launchpad** (`operation` `launchpad-purchase`): a `pocket` or an `origin` payment method, and the Launchpad sale in `destination.launchpad`. `amount` is expressed in `currency`. With `type` `REA` (the default, except for `purchase`) the destination receives exactly `amount` and the fees are added to what the origin pays; with `SEA` (the default for `purchase`) the origin pays exactly `amount` and the fees are taken from what the destination receives. The user needs at least the basic (Express) identity verification level, except for the Pro trading account operations, and the complete level for recurring operations (any `frequency` other than `punctual`). The `4xx` bodies other than `400` field validation and `403` carry a copy of the whole error in `data`, so their details are under `data.data`. - [Get the details of one wallet transaction](/docs/wallet/api-reference/wallet/v1/wallet/transaction/id/get): Returns one movement of the authenticated user's wallet, with more detail than the lists: the fees, the conversion rate, the hash of the blockchain transaction, the user's note and, with `userCurrency`, the amounts valued in that currency. The user must be the sender or the receiver; any other id is answered with `404`, the same as an id that does not exist. A movement whose processing failed is reported here with status `pending`. - [Set the user's note on a transaction](/docs/wallet/api-reference/wallet/v1/wallet/transaction/id/put): Sets the authenticated user's private note on one of their transactions. Sender and receiver each have their own note, and each of them only sees their own, as `note` in `GET /v1/wallet/transaction/{id}`. Setting it again replaces the previous text. The note cannot be cleared: an empty `note` changes nothing and is answered with `404`. - [Get the deposit addresses of a pocket, creating one if needed](/docs/wallet/api-reference/wallet/v2/wallet/pocket/pocketid/network/address/get): Returns the addresses where the pocket can receive deposits on a blockchain network. When the pocket has none on that network yet, one is created and returned. Deposits sent to a returned address, with its `tag` when present, go to this pocket. Requires the complete identity verification level; below it the call answers `401`. The network must support the pocket's asset. While the address of the pocket is being created, other calls answer `412`; retry after a moment. - [List the user's wallet transactions (cursor pagination)](/docs/wallet/api-reference/wallet/v3/wallet/transaction/get): Returns the movements of the authenticated user's wallet, newest first, one page at a time. To read the next page, send the `pageInfo.endCursor` of the previous response as `cursor` and keep the same filters. Stop when `pageInfo.hasNextPage` is `false`; `endCursor` is `null` only when the page is empty. All filters are optional and combine with AND. Each item has the shape of `GET /v1/wallet/transaction/{id}` without the details: the fees, the user's note and the amounts valued in another currency are only returned there. Buys, sells and swaps appear only once they are `completed`, and a transfer between two different users appears as a `withdrawal` to the sender and as a `deposit` to the receiver. - Earn - [Create earn movement](/docs/wallet/api-reference/earn/v1/earn/movements/post): Creates a deposit or withdrawal movement in Earn for the authenticated user. For deposits, the amount is transferred from the user's main wallet to the earn wallet. For withdrawals, it is transferred back. An optional `lockPeriodId` can be specified to deposit into a locked earn wallet. Returns the `movementId` and the corresponding `walletMovementId`. - [Get earn summary](/docs/wallet/api-reference/earn/v1/earn/summary/get): Returns a summary of the authenticated user's earn balances and total rewards, converted to the requested `userCurrency`. - [Get rewards configuration for all wallets](/docs/wallet/api-reference/earn/v1/earn/wallets/rewards/config/get): Returns the reward currency configuration for all earn wallets of the authenticated user. Each entry shows the wallet's currency and its selected reward currency. - [Get one earn wallet](/docs/wallet/api-reference/earn/v1/earn/wallets/walletid/get): Get details of a specific earn wallet - [Get earn wallet movements](/docs/wallet/api-reference/earn/v1/earn/wallets/walletid/movements/get): Get movements for a specific earn wallet - [Get reward settings by wallet](/docs/wallet/api-reference/earn/v1/earn/wallets/walletid/rewards/config/get): Returns the reward currency configuration for a specific earn wallet. - [Update wallet reward currency](/docs/wallet/api-reference/earn/v1/earn/wallets/walletid/rewards/config/patch): Changes the currency in which rewards are paid for a specific earn wallet. The `rewardCurrency` must be one of the allowed reward currencies for the wallet's pool. - [Get wallet's rewards summary](/docs/wallet/api-reference/earn/v1/earn/wallets/walletid/rewards/summary/get): Returns accumulated rewards and total converted reward for a wallet - [Get current APY rates by currency](/docs/wallet/api-reference/earn/v2/earn/apy/get): Returns the current annual percentage yields grouped by currency. Each currency key maps to an object whose keys are reward periods (`daily`, `weekly`, `monthly`) and whose values are the corresponding APY as a number. This is a public catalog endpoint — no authentication required. - [Get supported earn currencies](/docs/wallet/api-reference/earn/v2/earn/assets/get): Returns information about all supported earn currencies, including deposit/withdrawal status, allowed reward currencies, lock periods, APY boosts, tags, and category membership. Optionally filter by pool type (`partner`, `farming-pool`). This is a public catalog endpoint — no authentication required. - [List earn wallets](/docs/wallet/api-reference/earn/v2/earn/wallets/get): Returns the authenticated user's earn wallets, each showing the currency, balance, and optional lock period. Supports sorting by currency or balance, and pagination via `offset` / `limit`. - Account - [Delete account](/docs/wallet/api-reference/account/v1/account/delete): Deletes the authenticated user's account. This action is irreversible and removes all account data, wallets and associated information. The gateway injects the authenticated user's identity; the caller does not send it. - [Delete address](/docs/wallet/api-reference/account/v1/account/address/delete): Removes an address from the authenticated user. The `addressId` query parameter identifies which address to delete. - [Update address](/docs/wallet/api-reference/account/v1/account/address/put): Updates an existing address for the authenticated user. The `addressId` query parameter identifies which address to modify. - [Get deposit estimations](/docs/wallet/api-reference/account/v1/account/deposit-estimation/get): Returns the list of available deposit estimation ranges. Each range represents a bracket (minimum–maximum) the user can select during onboarding. - [Start two-factor authentication setup](/docs/wallet/api-reference/account/v1/account/settings/sfa/post): Starts the process to enable Google Authenticator (TOTP) two-factor authentication. Returns a QR image, a shared secret, and a display name for the authenticator app. After calling this endpoint the caller must present the QR to the user and then call `PUT /v1/account/settings/sfa` with the six-digit code to complete enablement. If the user already has 2FA enabled the service returns `409`. If a previous SFA challenge is active the service may return `428` with SFA metadata. - [Complete two-factor authentication setup](/docs/wallet/api-reference/account/v1/account/settings/sfa/put): Completes the TOTP enablement started by `POST /v1/account/settings/sfa`. The caller provides the six-digit TOTP code from the authenticator app to verify that the server-side and client-side secrets match. Optionally pass `alwaysRequired: true` to enforce 2FA on every login. - [List subaccounts](/docs/wallet/api-reference/account/v1/account/subaccount/get): Returns the list of subaccounts linked to the authenticated main account, optionally filtered by subaccount type. - [Create subaccount](/docs/wallet/api-reference/account/v1/account/subaccount/post): Creates a subaccount linked to the authenticated main account. The subaccount receives its own `userId` and can operate independently within the scope granted by the main account. - [Start subaccount 2FA setup](/docs/wallet/api-reference/account/v1/account/subaccount/sfa/post): Starts the process to enable two-factor authentication for a subaccount. Returns the TOTP secret and QR code for the subaccount holder to configure their authenticator app. - [Complete subaccount 2FA setup](/docs/wallet/api-reference/account/v1/account/subaccount/sfa/put): Completes the process to enable two-factor authentication for a subaccount. Verifies that the TOTP on the server side and the TOTP on the client side match. - [Update account](/docs/wallet/api-reference/account/v1/account/update/put): Updates account information for the authenticated user. Accepts partial updates — only the fields present in the request body are modified. Fields protected by the current verification level or that already have a value cannot be overwritten; those attempts return `412`. This route uses `WrapResponseDataOnStatus4xx`: business errors from the backing service arrive wrapped inside `data` when the status is 4xx. The gateway injects the authenticated user's identity; the caller does not send it. - [Update user identity document](/docs/wallet/api-reference/account/v1/account/users/person/identity/put): Updates the identity document details (type, number, expiry date and country) for the authenticated user. Rejected if the user is already verified or has a pending verification, if the document is expired, or if the document number is already registered to another account. - [Get identity verification status](/docs/wallet/api-reference/account/v1/account/verify/identity/get): Returns the current status of the identity verification process for the authenticated user, including document images, KYC express status, risk level, extra measures, and tier information. - [Create address](/docs/wallet/api-reference/account/v2/account/address/post): Adds a new address to the authenticated user. Requires `nationalityCountryCode` in addition to the standard address fields. Replaces `POST /v1/account/address`. - [Get account details](/docs/wallet/api-reference/account/v3/account/get): Returns account details for the authenticated user. Personal data (name, surname, email, phone) is returned masked for privacy. The response includes the user's profile settings, verification state, company data (for business accounts), knowledge level and onboarding status. The gateway injects the authenticated user's identity; the caller does not send it. - K Y C - [Download subaccount identity file](/docs/wallet/api-reference/kyc/v1/verifier/subaccount/file/get): Downloads an identity verification file (document image or selfie) for a specific subaccount. The response is the raw binary file. - Funding - [Find blockchain addresses](/docs/wallet/api-reference/funding/v1/blockchain-manager/address/get): Returns the list of blockchain deposit addresses associated with a wallet pocket on the specified network. These are the addresses generated by the platform for the user to receive funds, not the external addresses registered in the address book. Both `network` and `walletPocketId` are required, and the pocket must belong to the authenticated user. An empty array means the pocket has no address ready on that network; request one with `POST /v1/blockchain-manager/address`. - [Create a blockchain address](/docs/wallet/api-reference/funding/v1/blockchain-manager/address/post): Generates a new blockchain deposit address for the given network and wallet pocket. The pocket must belong to the authenticated user. The address may not be ready immediately: with `status: pending` it is still being generated, and it shows up with its `address` in `GET /v1/blockchain-manager/address` once ready. - [List address book entries](/docs/wallet/api-reference/funding/v1/blockchain-manager/address-book/get): Returns the user's registered external blockchain addresses, optionally filtered by currency or network. Only entries in `validating` or `verified` state are returned. Entries in `validating` state are waiting for the user to confirm an authorization email; only `verified` ones are ready for withdrawals. - [Create an address book entry](/docs/wallet/api-reference/funding/v1/blockchain-manager/address-book/post): Registers a new external blockchain address in the user's address book for future withdrawals. The entry starts in `validating` state. An authorization email is sent to the user; the entry moves to `verified` only after the user confirms it. Real-time status updates arrive through the websocket event `address-book-updated-v1`. The address is checked against the format of `network`, and the same address cannot be registered twice for the same currency and network while an earlier entry is still `validating` or `verified`. - [Get address book entry](/docs/wallet/api-reference/funding/v1/blockchain-manager/address-book/addressid/get): Returns the details of a single address book entry of the authenticated user, identified by its UUID. Only entries in `validating` or `verified` state can be retrieved. - [Create a withdrawal draft](/docs/wallet/api-reference/funding/v1/blockchain-manager/order/withdrawal/draft/post): Creates a draft withdrawal order that must be accepted before it is submitted to the blockchain. The draft takes the destination address, network, tag and fees from the address book entry referenced by `addressBookId`, and debits the user's pocket of that currency with the highest balance; the caller only specifies how much to withdraw, either in the cryptocurrency or in a fiat currency. Checks the balance (including the network fee), the minimum amount for the network and that the user is allowed to withdraw. Nothing is debited yet. The draft expires at `expiresAt`; after that it cannot be accepted and a new one has to be created. - [Check if iban is valid](/docs/wallet/api-reference/funding/v1/teller/iban/validate/post): Checks whether an IBAN is well formed and its check digits are correct. It does not check that the account exists or who holds it. Send `iban` (required) and `countryCode` (optional) in the JSON body. This operation does not accept query parameters. An invalid IBAN is not an error: the response is `200` with `result: false`. - [Execute an order](/docs/wallet/api-reference/funding/v1/teller/order/post): Executes an order previously created with `POST /v1/teller/order/proforma`, charging it with the payment method chosen there. A proforma can be executed only once and only while it is valid, so an expired one has to be created again. When the user has to complete the payment, for example to pass 3-D Secure on a card or to approve a Bizum payment, the response comes with `status: waiting-user` and `provider.requestConfiguration` says how: open its `uri` when `type` is `iframe`, or wait for the user to approve it outside the app when `type` is `external`. - [Cancel an order](/docs/wallet/api-reference/funding/v1/teller/order/cancel/post): Changes an order status from `waiting-user` to `cancelled`. Use this when the user decides not to proceed with a card payment that is awaiting confirmation. - [Create an order proforma](/docs/wallet/api-reference/funding/v1/teller/order/proforma/post): Creates an order proforma: it prices the order, with its fees and any discount, without charging anything. Show the breakdown to the user and, if they accept, execute it with `POST /v1/teller/order` and the returned `orderId`. A proforma is valid for a limited time and can be executed only once. To refresh the price, create a new one. - [Get teller order status](/docs/wallet/api-reference/funding/v1/teller/order/status/get): Returns the current status of a teller order of the authenticated user, identified by its order ID or its wallet proforma ID. An ID that does not match any order of the user is not an error: the response is `200` with `status: pending`. - [Get pocket reference](/docs/wallet/api-reference/funding/v1/teller/pocket/reference/get): Returns the reference to deposit into a pocket by bank transfer, together with the bank accounts that accept the deposit. To fund the pocket, send a transfer to any of the accounts in `bankAccounts` with `pocket.reference` as the concept. The reference is assigned the first time it is requested and stays the same afterwards. - [Complete travel rule order](/docs/wallet/api-reference/funding/v2/blockchain-manager/travel-rule-order/orderid/post): Submits the travel-rule information of a crypto order of the authenticated user: who the counterparty is and what kind of wallet they use. For a deposit that is who sent the funds, and for a withdrawal who receives them. Compared with `POST /v1/blockchain-manager/travel-rule-order/{orderId}`, the counterparty's address is reduced to its country (`address.countryCode`), identity documents, place of birth and date of birth are not collected, and `ownershipVerified` can be sent for unhosted wallets. When `walletOwnership` is `other`, `personType`, `name` and `address` are required, and `surname` too unless `personType` is `company`. - Compliance - [Confirm an address book entry](/docs/wallet/api-reference/compliance/v1/compliance/address-book/addressbookid/confirm/post): Confirms a destination address in the address book without needing the email-based confirmation token. Intended for subaccounts that cannot receive the confirmation email directly. The authenticated user is treated as the address book owner. The operation is idempotent: if the entry is already approved the endpoint returns `204` without error. TOTP is sent via the `x-totp` header; only `gauth` is supported as delivery method. - Transfers - [List social pay orders](/docs/wallet/api-reference/transfers/v1/social-pay/order/get): Returns all social payment orders for the authenticated user, including both sent and received orders with their current status and status history. - [Create order (SCA)](/docs/wallet/api-reference/transfers/v2/social-pay/order/post): Creates a new social payment order. Requires 2FA via the `x-totp` header. When TOTP is missing, returns HTTP 428. When TOTP doesn't match, returns HTTP 420. Stablecoin operations may require SCA PIN verification. - [Claim user pending orders (SCA)](/docs/wallet/api-reference/transfers/v2/social-pay/order/claim/post): Claim user pay orders. Stablecoin operations may require SCA PIN verification. - [Create social pay order with two step verification](/docs/wallet/api-reference/transfers/v3/social-pay/order/post): Creates a new social payment order. The recipient is identified by email, phone, or alias depending on the `type` field. The amount is debited from the sender's pocket. This endpoint requires two step verification, and the verification is bound to this exact order: pocket, type, recipient, currency, amount, concept and note. 1. Call this endpoint without the verification headers. The response is a 428 with `data.ticket` and `data.operationId`. 2. Complete the verification with the ticket: call `POST /v1/auth/two-step-verification/initiate`, then `POST /v1/auth/two-step-verification/verify`. To send the code again or use a different channel, call `POST /v1/auth/two-step-verification/reissue`. 3. Repeat this request **with the same body**, the `proofToken` from the verify response in `x-two-step-verification-proof-token`, and the `data.operationId` from step 1 in `x-two-step-verification-operation-id`. A proof token can be used only once and expires two minutes after the verification. If it is missing, invalid, expired, already used, issued for a different operation, or the body changed, the response is a new 428 with a new ticket and operation ID. Start again from step 2 with those values. Stablecoin orders can also answer a 428 for SCA (`B2M_AUTH_SCA_*`, no `data`). Resolve it first, then repeat the request: the proof token is not spent by an SCA 428. Do not use `GET /v3/signin/sfa` or the `x-totp` headers for this endpoint. - Market - [List currency symbols](/docs/wallet/api-reference/market/v1/currency/catalog/get): Returns every supported currency symbol mapped to its display name. This replaces the deprecated `GET /v1/type`. The response is a flat object whose keys are symbols and whose values are names. The crypto catalogue includes testnet symbols such as `BTCTEST`; use `GET /v2/currency/assets` when you need to tell them apart. `type` is mandatory. Omitting it fails validation with `400`. No authentication is required. - [Get OHLC and average price for one asset](/docs/wallet/api-reference/market/v1/currency/ohlca/symbol/get): Returns open, high, low, close and average USD prices for one asset over a window that ends at `time` and spans `timeframe` backwards. With `timeframe=1D` and no `time`, the window is the last 24 hours. The symbol can be a crypto or a fiat currency. All prices are decimal strings in USD, derived from the stored rates against the dollar. `average` is the inverse of the mean rate over the window, which is a harmonic mean of the price rather than an arithmetic one. A value of `"0"` means the stored rate was zero. `404` means the service has no rates for that asset inside the window. No authentication is required. - [List asset prices by interval](/docs/wallet/api-reference/market/v1/currency/prices/get): Returns the current price of every crypto asset in one quote currency, plus the price one interval ago for each requested interval (for `one_day`, the price 24 hours earlier). `time` is the epoch-millisecond timestamp of each point. The service caches these results, so the live quote can be slightly behind the current time. The outer key is the asset symbol. Each value is an array whose first entry is always the live quote, without an `interval` field. One entry per requested `interval` follows, in the order the intervals were requested, each carrying its `interval`. Use the pairs to compute price changes over those periods. `price` is a decimal string: the price of one unit of the asset in `currency`. `"0"` means no price is available for that asset at that point, which is common for testnet symbols. No authentication is required. - [List USD exchange rates](/docs/wallet/api-reference/market/v1/currency/rate/get): Returns exchange rates against the US dollar for every supported fiat and crypto symbol. Each rate is how many units of that currency equal one US dollar: `EUR: 0.86` means 1 USD = 0.86 EUR, and `BTC: 0.0000126` means 1 USD = 0.0000126 BTC. To convert an amount from A to B, multiply by `rate[B] / rate[A]`. The response is an array with one element per requested timestamp, in request order, or a single element for the current time when `time` is omitted. Each element has a `fiat` map, a `crypto` map, or both, depending on `type`. No authentication is required. - [List all assets](/docs/wallet/api-reference/market/v2/currency/assets/get): Returns metadata for every asset the platform knows, keyed by symbol. Fiat and crypto assets share the same shape. Testnet variants (`testnet: true`) are **included by default**; pass `includeTestnet=false` to drop them. Delisted assets are also returned and carry `removedAt`, so filter on it before offering an asset to users. No authentication is required. - [Get asset metadata](/docs/wallet/api-reference/market/v2/currency/assets/symbol/get): Returns metadata for a single asset. The shape matches one entry of `GET /v2/currency/assets`. The lookup is an exact, case-sensitive match on the symbol: `BTC` works, `btc` returns `404`. Testnet and delisted assets are returned like any other; check `testnet` and `removedAt`. No authentication is required. - [Get historic price chart](/docs/wallet/api-reference/market/v3/currency/chart/get): Returns a time series for a currency pair, ready to draw a price chart. Each row is `[time, baseRate, quoteRate]`: Unix epoch milliseconds, then the rate of each currency against the US dollar (units per 1 USD, as in `GET /v1/currency/rate`). The price of the base in the quote currency is `quoteRate / baseRate`. Either rate is `null` when there is no data at that timestamp; skip those rows instead of plotting zero. `temporality` selects both the time range and the spacing between points. Rows are ordered oldest first. `all-time` is not available between two fiat currencies and returns a `400` with a different body shape (`errorCode` instead of `statusCode`). No authentication is required. - [Get ticker data for one asset](/docs/wallet/api-reference/market/v3/currency/ticker/symbol/get): Returns the price and market statistics of one crypto asset in a chosen currency. The response is a two-level map: the outer key is `rateCurrency` (or `USD` when it is omitted) and the inner key is the path `symbol`. The array under it depends on `interval`: - Without `interval`, one entry with the live quote and no `interval` field. - With `interval`, one entry per requested interval holding the price one interval ago, and no live quote. Request the endpoint twice if you need both. Market statistics (`marketCap`, `totalVolume`, `fullyDilutedMarketCap`, `maxSupply`, `totalSupply`) are always the current values, converted to `rateCurrency`, and are omitted when the service has no data for them. The service does not reject unknown symbols. An unknown `symbol` returns `[null]` (without `interval`) or `[]` (with it), and an unknown `rateCurrency` returns `price: "0"`. No authentication is required. - Loan - [Get the amount required to open a loan at 50% LTV](/docs/wallet/api-reference/loan/v1/loan/ltv/get): Returns the missing amount so a new loan would open at the creation LTV (`0.50`). Send exactly one of `guaranteeAmount` or `loanAmount`; the other is derived from current prices. Sending both, or neither, is rejected. Also returns both amounts in `userCurrency` and the base APR of `loanCurrency` before the user's discounts. `ltv` is a ratio (`0.50` is 50 %). Nothing is created or reserved. Use these currencies and amounts to preview the contract with `POST /v1/loan/pre-contract` (optional) and to open the loan with `POST /v1/loan/orders`. - [List loan movements](/docs/wallet/api-reference/loan/v1/loan/movements/get): Returns the movements of the authenticated user's loan orders, newest first. Only `completed` movements are listed. Amounts are converted to EUR at the prices of each movement. Filter by `orderId` to get the history of one order, and by `type` to get one kind of movement. Page through the results with `limit` and `offset`; `total` is the number of movements matching the filters. `payload` depends on `type`. Each example of the 200 response is one movement of a different type. - [List loan orders](/docs/wallet/api-reference/loan/v1/loan/orders/get): Returns the authenticated user's loan orders, newest first, with their values in EUR at current prices, what is left to repay and the state of their interest payments. Filter by `status` and page through the results with `limit` and `offset`; `total` is the number of orders matching the filters. - [Create loan order](/docs/wallet/api-reference/loan/v1/loan/orders/post): Requests a loan for the authenticated user. The guarantee is taken from the user's wallet and the loan is approved and paid into the wallet in the same call, so the order is returned `active` together with its `request` and `approve` movements. Get the amounts first with `GET /v1/loan/ltv`: the order is refused when its LTV goes too far above the 50 % used for new loans. Optionally, preview the contract first with `POST /v1/loan/pre-contract`. The user must be fully verified and have a valid residence address, both currencies must be enabled in `GET /v2/loan/currency/configuration`, and `loanAmount` must be at least the `minimumAmount` of the loan currency. - [Get loan order by ID](/docs/wallet/api-reference/loan/v1/loan/orders/orderid/get): Returns one of the authenticated user's loan orders, with its values in EUR at current prices, what is left to repay and the state of its interest payments. - [Increase loan guarantee](/docs/wallet/api-reference/loan/v1/loan/orders/orderid/guarantee/increase/post): Adds guarantee to an `active` loan, taking it from the user's wallet, which lowers the LTV and the liquidation price. The response returns the updated order and the `guarantee_increase` movement created; `guaranteeOriginalAmount` does not change. - [Pay back a loan](/docs/wallet/api-reference/loan/v1/loan/orders/orderid/payback/post): Repays part or all of an `active` loan with funds of the loan currency taken from the user's wallet. Accrued interest is paid first and the rest reduces the principal. When `paybackAmount` covers the remaining debt, only the remaining debt is charged, the order becomes `completed` and the guarantee is returned to the wallet. The response returns the updated order and the `payback` movement created. - [Render a pre-contract preview for a loan order](/docs/wallet/api-reference/loan/v1/loan/pre-contract/post): Renders the current version of the loan contract as an HTML document, so the user can read it before requesting the loan with `POST /v1/loan/orders`. Nothing is created. The document is filled in with the conditions sent in the body and with the authenticated user's name, surname, identity document number, email, phone and residence address. It assumes the 50 % LTV used for new loans and a one-year term. `class` and `style` attributes are removed from the HTML. - [Get loan currency configuration](/docs/wallet/api-reference/loan/v2/loan/currency/configuration/get): Lists the currencies that can be borrowed, with their APR, limits and available liquidity, and the currencies that can be pledged as guarantee, with their LTV settings. Disabled currencies are listed too; check `enabled` before offering them. This is a public endpoint: it needs no authentication. `liquidity` and `liquidityStatus` may take a few moments to reflect the latest loans. - Misc - [List regions for a country](/docs/wallet/api-reference/misc/v1/misc/country/countryisocode/region/get): Returns the first-level subdivisions of a country, such as states or autonomous communities, sorted by `name`. Codes follow [ISO 3166-2](https://en.wikipedia.org/wiki/ISO_3166-2) without the country prefix: Andalusia is `AN`, not `ES-AN`. Region entries carry `iso`, `name` and `fips`. They do **not** include `iso3`, which appears only on the country list returned by `GET /v1/misc/country`. A well-formed code with no data returns `200` with an empty array, not `404`. Curaçao (`CW`), Kosovo (`XK`) and Gibraltar (`GI`) return a single entry for the territory itself, with the country code as `iso` and `fips` `00`. No authentication is required. - Brokerage - [Create a draft order](/docs/wallet/api-reference/brokerage/v1/brokerage/draft/post): Quotes an instant buy or sell and returns a draft you can execute with `POST /v1/brokerage/draft/approve`. Creating a draft moves no funds. It resolves the price, computes fees and runs the same checks the execution will run — funds, limits, pair availability — so a rejection here means the trade cannot go ahead as requested. `pair` is written `BASE/QUOTE`. `amount` and `amountCurrencySymbol` fix one side of the trade; see `amountCurrencySymbol` for which one. Omit `paymentMethod` to settle against your wallet balance, or send `source: teller` to charge an external method. A draft is valid for a short time and can be approved only once. Create a new draft if it expires or its approval fails. Every error body has `code` and `description`. Errors found while processing the draft also carry `type`, a stable identifier to branch on, and often `data` with the values involved. Errors about the request format carry neither. - [Approve a draft order](/docs/wallet/api-reference/brokerage/v1/brokerage/draft/approve/post): Executes a draft created with `POST /v1/brokerage/draft` and returns the resulting order, whose `orderId` is the `draftId` of the draft. A draft can be used only once: the first approval attempt consumes it, even when that attempt is rejected. After an error, create a new draft. Drafts that expired, were already used or belong to another user are reported as `DRAFT_NOT_FOUND`. Funds, limits and the availability of the operation are checked again, so a draft that was valid when quoted can still be rejected here — for example with `NOT_ENOUGH_FUNDS` if your balance changed, or `PRICE_PROTECTION` if the price moved too far. A `200` means the order was created, not that it has settled. With `source: teller` the order is usually `payment-pending`, and `paymentMethod` carries the payment session the user has to complete. Follow the order with `GET /v1/brokerage/order/{orderId}` until it reaches a final status. Error bodies follow the same rules as `POST /v1/brokerage/draft`: `type`, and often `data`, are present except on request format errors. - [Get order setting](/docs/wallet/api-reference/brokerage/v1/brokerage/order-setting/key/get): Returns a platform-wide brokerage setting. The value is the same for every user. - `SLIPPAGE_MAX_PERCENTAGE`: maximum price change tolerated between the quoted price and the current price, as a fraction (`0.05` is 5 %). - `MIN_EXECUTION_EUR_LIMIT`: EUR value from which a trade is executed with `type` `execution`; smaller trades are `exchange`. It is not a minimum order amount. Values are decimal strings, not numbers. - [Get order by ID](/docs/wallet/api-reference/brokerage/v1/brokerage/order/orderid/get): Returns one of your brokerage orders, wrapped in an `order` property. Use it to follow an order after `POST /v1/brokerage/draft/approve` until `status` reaches a final value. Orders of other users are reported as not found. - **Pro** - [Changelog](/docs/pro/changelog): Deprecated Spot Trading API endpoints and what to use instead. - [Errors](/docs/pro/errors): HTTP statuses and order error codes returned by the Spot Trading API, over REST and WebSocket. - [First order in minutes](/docs/pro/first-order): Place a signed Pro spot order with a known HMAC fixture. - [Fetch market data](/docs/pro/market-data): Pro OHLCV intervals, public book and trades, and the published limit cap. - [Introduction](/docs/pro/overview): Trade Bit2Me Pro spot markets from your code: read public market data, place and cancel orders over REST, and stream order book, fills, and balances over WebSocket. - [Rate limits](/docs/pro/rate-limits): Requests per minute by IP, per-endpoint REST limits, WebSocket limits per connection and command, and open orders per market for Spot Trading API. - [Overview](/docs/pro/rest-overview): How to use the generated Spot Trading API OpenAPI reference on this site. - [Order rules](/docs/pro/trading-rules): Order types and expiry for Spot Trading API. - [Order commands](/docs/pro/websocket-commands): Create and cancel orders over the Pro WebSocket, in batch, and with a kill switch. - [Futures WebSocket](/docs/pro/websocket-futures): Limited availability — perpetual public channels until product confirms a full launch. - [Private channels](/docs/pro/websocket-private): my-trades, my-orders, executions, my-balance, my-working-capital. - [Public channels](/docs/pro/websocket-public): Order book Level 2 and public trades — no authentication. - [Pro WebSocket](/docs/pro/websocket): Connect to wss://ws.bit2me.com/v1/trading, authenticate, subscribe. - Api reference - Market Data - [Get OHLCV candles](/docs/pro/api-reference/marketdata/v1/trading/candle/get): Returns OHLCV candles (open, high, low, close, volume) of a market between `startTime` and `endTime`. No authentication is required. Sort by the timestamp (`[0]`) before plotting. The last candle is the current one and is still changing. Intervals with no trades produce no candle, so the series can have gaps: fill them on the client if a continuous series is needed. A request returns at most `limit` candles. To cover a longer range, split it into windows of `limit * interval` and request them one after another. - [Get last trades](/docs/pro/api-reference/marketdata/v1/trading/trade/last/get): Returns the most recent public trades of a market, newest first, as compact positional tuples `[side, price, amount, timestamp]`. No authentication is required. At most 50 trades are returned; a larger `limit` is silently reduced to 50. For a live feed use the trading websocket instead of polling. - [List market configurations](/docs/pro/api-reference/marketdata/v2/trading/market-config/get): Returns the markets available to the caller and the rules an order must respect in each one: amount and price limits, minimum order value and decimal precision. Validate orders against these values before sending them to avoid `412` rejections. Authentication is optional and changes the result: `restricted` markets are listed only for the users granted access, `disabled` markets are never listed, and `enabled_at` markets are listed once their opening date has passed. The response is a plain array; when `limit` is not sent, every market is returned. - [Get the order book](/docs/pro/api-reference/marketdata/v2/trading/order-book/get): Returns a snapshot of the aggregated order book of a market: resting orders grouped by price, up to 100 levels per side. No authentication is required. The snapshot can be a few moments old: rely on `timestamp` to know when it was taken, and use the trading websocket for a live book. - [Get ticker statistics](/docs/pro/api-reference/marketdata/v2/trading/tickers/get): Returns 24-hour statistics (open, close, high, low, volumes, change) and the best bid and ask of every market, or only of `symbol` when it is sent. The response is always an array, with a single entry when filtering by `symbol`. Authentication is optional. Without it, markets reserved to specific users (`restricted`) are not listed. - Trading - [List trading orders](/docs/pro/api-reference/trading/v1/trading/order/get): Returns the authenticated user's spot orders, filtered and paginated. At most 100 orders are returned per call: a larger `limit` is silently reduced to 100, so page with `offset` until a page comes back shorter than `limit`. Open orders include `inactive` ones (stop-limit orders waiting for their trigger). To list everything still pending, filter with `status_in=open,inactive` rather than `status=open`. - [Place a trading order](/docs/pro/api-reference/trading/v1/trading/order/post): Creates a spot order for the authenticated user and returns it as stored. - `limit`: `price` is required. - `stop-limit`: `price` and `stopPrice` are required. The order is created `inactive` and enters the book as a limit order at `price` once the market reaches `stopPrice`. - `market`: `price` is ignored. With `amountInQuote: true`, `amount` is read in the quote currency and converted to the base amount from the current order book. Amounts and prices are decimal strings. They must respect the market rules published by `GET /v1/trading/market-config` (`minAmount`, `maxAmount`, `minPrice`, `maxPrice`, `minOrderSize`, `pricePrecision`, `amountPrecision`); an order that breaks one is rejected with `412` and an `errorPayload.code` that names the rule. Follow the order's progress with `GET /v1/trading/order/{id}` and its fills with `GET /v1/trading/order/{id}/trades`. - [Get a trading order](/docs/pro/api-reference/trading/v1/trading/order/id/get): Returns one of the authenticated user's orders. An order of another user answers `404`, the same as one that does not exist. - [Cancel a trading order](/docs/pro/api-reference/trading/v1/trading/order/id/delete): Cancels one of the authenticated user's orders and returns it with `status: cancelled` and `cancelReason` starting with `CR-1`. The part already filled stays filled; the funds still reserved are released to the trading wallet. Only `open` and `inactive` orders can be cancelled; any other status answers `412` `DELETE_CLOSED_ORDER`. - [List trades for an order](/docs/pro/api-reference/trading/v1/trading/order/id/trades/get): Returns every execution (fill) of one of the authenticated user's orders, unpaginated. An order that has not filled yet returns an empty array. Compared with `GET /v1/trading/trade`, each trade also carries `feePercentageDiscount` and `spaceCenterLevelId`. - [List user trades](/docs/pro/api-reference/trading/v1/trading/trade/get): Returns the authenticated user's trades (fills), filtered and paginated, together with the total number of trades that match the filters. At most 50 trades are returned per call: a larger `limit` is silently reduced to 50. Use `total` and `offset` to walk the remaining pages. - Funding - [List historical movements](/docs/pro/api-reference/funding/v1/trading/movement/get): Returns the movements of funds into and out of the authenticated user's trading wallet, newest first: their own deposits and withdrawals, adjustments made by Bit2Me, automatic working capital refills and funds assigned to or released from their trading bots. At most 100 movements are returned and there is no offset: when more could match, split the query into shorter `from`/`to` ranges. - [List trading wallet balances](/docs/pro/api-reference/funding/v1/trading/wallet/balance/get): Returns the balances of the authenticated user's trading (Pro) wallets, one entry per currency wallet. Only these funds can be used to place orders; move funds in and out with `POST /v1/trading/wallet/deposit` and `POST /v1/trading/wallet/withdraw`. `blockedBalance` includes both the funds reserved by open orders and the funds assigned to the user's trading bots. - [Deposit into trading wallet](/docs/pro/api-reference/funding/v1/trading/wallet/deposit/post): Moves funds from the user's Bit2Me wallet into their trading wallet, where they become available to place orders. The funds are taken from the user's pocket of `currency` with the highest balance, which must hold at least `amount`. The transfer is recorded as a `deposit` movement (`GET /v1/trading/movement`), and the trading wallet of the currency is created on the first deposit. Only one movement per currency can be in progress at a time. - [Withdraw from trading wallet](/docs/pro/api-reference/funding/v1/trading/wallet/withdraw/post): Moves funds from the user's trading wallet back to their Bit2Me wallet, to the user's pocket of `currency` with the highest balance. Only the available `balance` can be withdrawn; funds reserved by open orders must be released first by cancelling those orders. The transfer is recorded as a `withdrawal` movement (`GET /v1/trading/movement`). `amount` is rounded down to the decimals of the currency. Only one movement per currency can be in progress at a time. - [List working capital limits](/docs/pro/api-reference/funding/v1/trading/working-capital/get): Returns the working capital limits configured for the authenticated user: how much of each currency Bit2Me may top up automatically into the trading wallet over a rolling 24-hour window, and how much of it has been used. Users without working capital get an empty array. - WebSockets Authentication - [Sign in with API key](/docs/pro/api-reference/wsauth/v1/signin/apikey/post): Authenticates a user using an API key and returns a JWT access token. The API key must be sent via the `ApiKeyAuth` security scheme. The request body carries the `userId` that the key belongs to. On success the response contains an `accessToken` with its expiration timestamp. - **Partner** - [Apple Pay and Google Pay](/docs/partner/apple-google-pay): Wallet-pay funding via Teller proforma, execute, and Paylands checkout. - [Partner architecture](/docs/partner/architecture): Parent HMAC, subaccount sessions, and the money path for B2B2C. - [Add card widget](/docs/partner/embed-add-card): Load embed.bit2me.com/add-card in a WebView after signin. - [Identity widget](/docs/partner/embed-identity): Initialize KYC and open redirectUrl in a native browser. - [Fiat deposits and withdrawals](/docs/partner/fiat): Bank transfer, card, and Teller orders for EUR and BRL; SEPA and Pix withdrawals. - [KYB (company subaccount)](/docs/partner/kyb): Onboard a legal entity as type company — no identity webview. - [KYC (end user)](/docs/partner/kyc): Verify a natural-person subaccount, including session cap, enhanced measures, and 409 phone versus email. - [Partner overview](/docs/partner/overview): B2B2C journeys: onboard end users, fund fiat, exchange, and withdraw crypto. - [Partner REST overview](/docs/partner/rest-overview): Embed reference plus the Wallet routes partners actually call. - [Social Pay vs pocket transfer](/docs/partner/transfers): Two different rails. Do not treat Social Pay as silent institutional treasury. - [Travel Rule](/docs/partner/travel-rule): Wallet legacy only: confirm the proforma, then POST /v2/blockchain-manager/travel-rule-order with the operation id. - [Embed widgets](/docs/partner/widgets): Embed dashboard auth flow, identity in a native browser, add-card in a WebView, and theme customization. - [Crypto withdrawals (address book)](/docs/partner/withdrawals-address-book): Verify the destination, draft without type, then POST /v2/.../draft{orderId}. Do not call travel-rule-order. - [Crypto withdrawals (Wallet legacy)](/docs/partner/withdrawals-wallet): Proforma, confirm that id, then Travel Rule with the operation id. Still live. - Api reference - Auth flow - [Create subaccount](/docs/partner/api-reference/auth-flow/v1/account/subaccount/post): Creates a subaccount linked to the authenticated main account. The subaccount receives its own `userId` and can operate independently within the scope granted by the main account. - [Sign in with API key](/docs/partner/api-reference/auth-flow/v1/signin/apikey/post): Authenticates a user using an API key and returns a JWT access token. The API key must be sent via the `ApiKeyAuth` security scheme. The request body carries the `userId` that the key belongs to. On success the response contains an `accessToken` with its expiration timestamp. - Embed development activities - [Authorize Transaction](/docs/partner/api-reference/embed-development-activities/authorizeTransaction): Endpoint in your backend used by Bit2Me for request authorization on each transaction. Your backend exposes this endpoint (`POST /v1/b2m/transaction/authorize` on your own domain); Bit2Me calls it. - [Report Transaction](/docs/partner/api-reference/embed-development-activities/reportTransaction): Endpoint in your backend used by Bit2Me to report transaction operations. Your backend exposes this endpoint (`POST /v1/b2m/transaction/report` on your own domain); Bit2Me calls it. - **AI** - [Claude Desktop setup](/docs/ai/claude): Register bit2me in claude_desktop_config.json. - [Cursor setup](/docs/ai/cursor): Add @bit2me/mcp-server to Cursor MCP settings. - [MCP errors](/docs/ai/errors): 401, nonce, 429, 400, and funds errors when using the MCP server. - [Bit2Me MCP](/docs/ai/overview): Local MCP server: 48 tools for Wallet, Pro, Earn, Loans, and portfolio. - [MCP tool catalog](/docs/ai/tools): 48 tools grouped by category, from bit2me-devs/bit2me-mcp. - **Troubleshoot** - [Fix HMAC 401](/docs/recipes/hmac-401): Clock, nonce window, header names, and the known-answer fixture. - [Too many requests](/docs/recipes/rate-limit): Back off inside Starter 600 / Medium 800 / Pro 1000 RPM. - [Missing subaccount header](/docs/recipes/subaccount-header): Empty balances and parent-scoped calls when X-SUBACCOUNT-ID is omitted. - [Two-factor authentication](/docs/recipes/totp)