Crypto Exchange API Integration

At SwapSDK, we provide an API for embedding cryptocurrency exchange into a website, app, wallet, or service. The integration is built around several practical entities: instruments, pairs, address validation, orders, and status tracking. For new connections, it makes sense to use V2 with access keys, HMAC request signing, and IP whitelist.

View Integration Flow Request API Access

What the integration includes

The basic flow looks like this:

load available instruments;
determine the required pair;
validate the destination address through validate-address;
create an order;
show the user the depositAddress;
track status by orderId;
optionally attach an email to the order for notifications.

This is the practical integration scenario. The product does not just вЂњconnect exchange.вЂќ It manages a specific user path: pair selection в†’ data validation в†’ order creation в†’ deposit screen в†’ statuses в†’ completion.

1. Instruments: what data the product receives

The instruments section is used to build the exchange form. It returns a list of active instruments, as well as details for a specific currency and network. Responses typically include fields such as currencyTitle, networkTitle, precisionDecimals, requiresMemo, instrumentType, and contractAddress. These fields are what allow the form and backend validation to work correctly.

What to use on the frontend

currencyTitle and networkTitle вЂ” for asset and network selection;
precisionDecimals вЂ” to limit the number of decimal places;
requiresMemo вЂ” to show the memo/tag field in advance;
contractAddress вЂ” if the token contract is needed for the network.

Example: get the list of active instruments

curl -X GET '/api/v2/instruments/public' \
 -H 'accept: application/json'

Example: get details for one instrument

curl -X POST '/api/v2/instruments/public/one' \
 -H 'accept: application/json' \
 -H 'Content-Type: application/json' \
 -d '{
   "currencyTitle": "USDT",
   "networkTitle": "TRC20"
 }'

2. Pairs: how the exchange route is determined

A pair is not just вЂњBTC to USDT.вЂќ A pair links a specific sending instrument and a specific receiving instrument, including the network. Through the pair layer, the product gets the route parameters required for pricing and execution.

When to call pairs

after the user selects вЂњfromвЂќ and вЂњtoвЂќ;
before showing min/max and exchange conditions;
before moving to create-order.

Example: get pair data

curl -X GET '/api/v2/pairs/one?instrumentFromCurrencyTitle=BTC&instrumentFromNetworkTitle=BTC&instrumentToCurrencyTitle=USDT&instrumentToNetworkTitle=TRC20' \
 -H 'accept: application/json' \
 -H 'X-Api-Public-Key: yourPublicKey' \
 -H 'X-Api-Timestamp: 1691399446000' \
 -H 'X-Api-Signature: yourHmacSignature'

Instruments define asset and network parameters.
Pairs define the exchange route.
Correct pair selection makes the exchange flow more accurate and safer.

3. Address validation: checking address and memo before create-order

Address validation must happen before order creation. For this, V2 uses the validate-address method, which checks the correctness of address and memo for the selected currencyTitle and networkTitle.

curl -X POST '/api/v2/instrument/validate-address' \
 -H 'accept: */*' \
 -H 'X-Api-Public-Key: yourPublicKey' \
 -H 'X-Api-Timestamp: 1691397292905' \
 -H 'X-Api-Signature: yourHmacSignature' \
 -H 'Content-Type: application/json' \
 -d '{
   "currencyTitle": "USDT",
   "networkTitle": "TRC20",
   "address": "THUmkPhry61edcTf79yTioV6292ccsuCjV",
   "memo": "2345678",
   "getRejectReason": true
 }'

What matters in the UI

do not let the form proceed without successful validation;
show the memo/tag field only when it is actually required;
clearly warn users about memo/tag requirements for the relevant networks.

4. Orders: how an order is created

After the input data is validated, the backend creates an order. The create-order response returns key order details, including orderId, deposit details, and route parameters.

curl -X POST '/api/v2/orders/public/create' \
 -H 'accept: application/json' \
 -H 'X-Api-Public-Key: yourPublicKey' \
 -H 'X-Api-Timestamp: 1691397873000' \
 -H 'X-Api-Signature: yourHmacSignature' \
 -H 'Content-Type: application/json' \
 -d '{
   "instrumentFrom": {
     "currencyTitle": "USDT",
     "networkTitle": "TRC20"
   },
   "instrumentTo": {
     "currencyTitle": "BTC",
     "networkTitle": "BTC"
   },
   "destinationAddress": "bc1qexampleaddress",
   "destinationAddressMemo": null,
   "rateMode": "FLOATING"
 }'

Crypto Swap Widget

5. Status tracking, email, and the post-order screen

After an order is created, the product needs a clear post-order screen. The backend stores orderId, and the frontend regularly receives updates: deposit found, confirmations received, exchange in progress, withdrawal sent, exchange completed.

curl -X POST '/api/v2/orders/public/set-email' \
 -H 'accept: application/json' \
 -H 'Content-Type: application/json' \
 -H 'X-Api-Public-Key: yourPublicKey' \
 -H 'X-Api-Timestamp: 1691397292905' \
 -H 'X-Api-Signature: yourHmacSignature' \
 -d '{
   "orderId": 12345,
   "userEmail": "[email protected]"
 }'

6. Security layer: what is required for V2

For new integrations, V2 is the default model: publicKey and secretKey; HMAC request signing; IP whitelist; access granted by request.

7. Rate mode, fixed/floating, and additional scenarios

Create-order and order responses use fields such as rateMode and feeMode. In practice, this means the integration can be built around a more flexible market model or a more predictable fixed scenario, depending on the product.

Python Crypto Exchange API

Get Access to Crypto Exchange API

If you need an API for a website, app, wallet, or B2B service, submit a connection request. We provide access by request so we can define the integration format, product type, and required model in advance: API only or API + widget.

Request Access

FAQ

What should the backend do before create-order?

Load instruments, determine the pair, validate address/memo, and only then create the order.

Which instrument fields are actually needed by the form?

Usually currencyTitle, networkTitle, precisionDecimals, requiresMemo, and, when needed, contractAddress.

What must be stored after create-order?

At minimum orderId and depositAddress; if the network requires it, also depositAddressMemo.

How often should order status be polled?

A practical interval is 5вЂ“15 seconds with backoff for 429/5xx.

Can email notifications be sent for an order?

Yes, through set-email after order creation.

Which API version is better for a new integration?

For new integrations, V2 is the logical choice with publicKey, secretKey, HMAC, and IP whitelist.