API sàn đổi tiền mã hoá: báo giá, lệnh và địa chỉ nạp tiền

EIDEX Merchant API v1 is a Crypto Exchanger API: Quotes, Orders, Deposit Addresses under a single integration point. Connect once to access live pricing, full order lifecycle management, deposit address issuance, withdrawals, and event webhooks — all through the base URL `https://eidex.io/api/merchant/v1`. This reference covers every endpoint in the API, the permission model that controls what each key can do, a three-step quick start, and a worked example of a complete exchange flow from quote to payout.

EIDEX Merchant API v1 is a crypto exchanger API with a single integration point: live quotes, order creation and tracking, deposit address management, withdrawals and event webhooks. The base URL is https://eidex.io/api/merchant/v1, and authentication uses a pair of headers.

Last updated: July 26, 2026 · Merchant API v1. The machine-readable specification is authoritative wherever this page and the spec differ.

Key Takeaways

• 14 endpoints in five groups: quotes, orders, addresses, withdrawals, webhooks.
• Three permission levels per key — READONLY, TRADING, WITHDRAW — so an integration only gets what it needs.
• 60 requests per minute per key, shared across all endpoints, with limit headers in every response.
• 15 blockchain networks for deposits; the pair list is pulled live from `GET /tickers` rather than hard-coded.
• No sandbox: development runs against the live base URL, safely via a READONLY key.

What the Crypto Exchanger API Does

Quotes

`GET /tickers` returns available trading pairs in one consistent format, so you do not maintain a connection to an external venue yourself. Pricing and order execution both run through our connected partner exchange, which makes the API a single integration point for quotes and settlement. The same rate feeds both your storefront and the order you submit, so the price a customer sees matches the price the exchange fills at.

Orders

The full trade lifecycle: `POST /order` creates an exchange order (pair, BUY/SELL side, MARKET/LIMIT type), `GET /order/{id}` returns its status, `GET /orders` lists them, and `POST /order/{id}/cancel` cancels. Your front end keeps its own logic.

Addresses, Deposits and Withdrawals

`GET /deposit-address?network=` issues a receiving address for a specific chain (the network parameter is required), `GET /deposit-addresses` lists issued addresses. `POST /address/reserve` locks an address to your request via its identifier (nonce), and `POST /address/release` returns it to the pool once the trade closes. `GET /balances` reports current merchant balances; `POST /withdraw` initiates payouts. The outcome arrives as a `withdraw.completed` webhook — there is currently no REST method to poll withdrawal status.

Webhooks

`GET` and `POST /webhooks` plus `DELETE /webhooks/{id}` manage event subscriptions. Two events are delivered today: `deposit.confirmed` and `withdraw.completed`. An order-execution event (`order.filled`) is reserved for a later release, so order statuses are polled via `GET /order/{id}` for now.

Your storefront and brand stay yours: the API supplies quotes, executes orders and handles settlement, while you build the customer-facing interface. All operations run under your merchant account — the API has no per-customer sub-accounts.

What a Crypto Exchanger API Key Unlocks: Quotes, Orders, and Deposit Addresses

Every key carries a set of permissions, and each permission opens its own range of operations. Give each integration the minimum it needs: a key without withdrawal rights cannot move funds out, even if it leaks.

Read access (READONLY):

• Live rates for every available trading pair — `GET /tickers`
• Merchant balances per asset, free and reserved — `GET /balances`
• A deposit address on the chain you need — `GET /deposit-address?network=`
• Every deposit address issued to you — `GET /deposit-addresses`
• Order list with cursor pagination — `GET /orders`
• Status of a specific order — `GET /order/{id}`

Trading (TRADING):

• Create an order: pair, BUY/SELL side, MARKET/LIMIT type — `POST /order`
• Cancel an order — `POST /order/{id}/cancel`

Withdrawals (WITHDRAW):

• Initiate a payout to an external address — `POST /withdraw`. Minimum amounts and daily limits apply; the outcome arrives as a `withdraw.completed` webhook.

Address pool and subscriptions (TRADING permission; listing subscriptions requires READONLY):

• Lock an address to your request via its identifier (nonce); repeating the call with the same nonce returns the same address — `POST /address/reserve`
• Return an address to the pool once the trade closes — `POST /address/release`
• Create, list and delete event subscriptions — `POST`/`GET /webhooks`, `DELETE /webhooks/{id}`

What a key does not grant:

• Managing keys themselves — issuing and revoking happens in the dashboard, not over the API
• Changing account settings, running verification, or trading on P2P
• Acting on behalf of other users — every call runs under your own merchant account

Quick Start in Three Steps

Step 1. Get your keys. Issue `X-API-Key` and `X-API-Secret` in your dashboard (Settings → API keys). The secret is shown once at creation — store it immediately. The same screen sets key permissions (READONLY / TRADING / WITHDRAW) and an optional list of allowed IP addresses.

Step 2. Request quotes.

curl -X GET "https://eidex.io/api/merchant/v1/tickers" \
  -H "X-API-Key: <your_api_key>" \
  -H "X-API-Secret: <your_api_secret>"

Step 3. Create an order. `POST /order` requires an `Idempotency-Key` header, which protects you from duplicate trades on retries. The key must carry the TRADING permission.

curl -X POST "https://eidex.io/api/merchant/v1/order" \
  -H "X-API-Key: <your_api_key>" \
  -H "X-API-Secret: <your_api_secret>" \
  -H "Idempotency-Key: <unique_request_id>" \
  -H "Content-Type: application/json" \
  -d '{"pair":"BTCUSDT","side":"BUY","type":"MARKET","amount":"0.001"}'

For a limit order add `"type":"LIMIT"` and `"price":"<price>"`. See the specification for the full field list and accepted values.

From there, subscribe to deposit and withdrawal webhooks and poll `GET /order/{id}` for order status.

Endpoint Reference

How an Exchange Flow Works

A typical desk trade comes down to six calls to the crypto exchanger API, and the sequence between your backend and the endpoints looks like this:

NaN. The customer picks a direction — your storefront pulls prices from `GET /tickers`.

NaN. Your backend reserves an address for the request: `POST /address/reserve` with network and nonce. Repeating the call with the same nonce returns the same address, so duplicate submissions do not break the flow.

NaN. The customer sends funds to the issued address.

NaN. A `deposit.confirmed` webhook arrives — from that point the incoming payment counts as confirmed.

NaN. Your backend creates the order: `POST /order` with an `Idempotency-Key` header; status is polled via `GET /order/{id}`.

NaN. The payout is initiated with `POST /withdraw`, and execution is reported by a `withdraw.completed` webhook. Once the trade closes, the address goes back to the pool through `POST /address/release`.

The same sequence covers both one-off requests and a stream of dozens of trades per hour: the bottleneck is usually chain confirmation time rather than the API.

Integration Scenarios

Exchange Website

The classic setup: a calculator on the page, rates pulled from `GET /tickers`, requests tracked in your own CRM. The API covers pricing, execution and settlement, while trading rules, customer verification and support stay on your side.

Telegram Bot

The same circuit without a website: a bot is the interface, and its backend talks to the same endpoints. Dialogue logic — pair selection, rate display, address issuance, deposit notification — rides on webhooks, so there is no need to poll statuses in a loop. It is convenient to issue a separate key here with READONLY and TRADING permissions, keeping payouts on a different circuit.

White-Label Desk

Storefront, brand and customer base are yours; the settlement layer sits on our side. The scenario runs on the same calls and differs only in how deeply you customise the interface — the crypto plumbing stays invisible to the end user behind your brand.

Rate Limits and Idempotency

A limit of 60 requests per minute applies per API key and is shared across all endpoints. Every response carries `X-RateLimit-Limit` and `X-RateLimit-Remaining` headers; exceeding the limit returns `429` with a `Retry-After` header holding the seconds until the next window.

`POST /order` and `POST /withdraw` require an `Idempotency-Key` header — the same pattern described in the IETF Idempotency-Key draft and used across payment APIs. Repeating a request with the same key and body returns the stored response instead of creating a duplicate, while the same key with a different body is rejected. This makes retries safe for money movements.

Each account supports up to 10 active API keys and 5 webhook subscriptions. Errors come back as a single JSON shape — `{"code", "message", "request_id"}` — and quoting `request_id` speeds up support requests.

Security and Key Permissions

Credentials travel in the `X-API-Key` and `X-API-Secret` headers — never in the query string or request body — so they stay out of browser history and intermediate proxy logs. The secret is never logged; internal records keep only a masked key prefix.

Key permissions bound what a key can do: READONLY for reads, TRADING for creating and cancelling orders, reserving and releasing deposit addresses and managing webhook subscriptions, WITHDRAW for payouts. Give each integration the minimum it needs — a leaked key without WITHDRAW cannot move funds out.

You configure IP whitelisting when issuing a key by listing addresses or subnets in CIDR notation. If you leave the list empty, the key is accepted from any address by default — for keys with WITHDRAW we recommend always setting the whitelist explicitly.

Webhooks are signed: every call to your handler carries an `X-Webhook-Signature` header with an HMAC-SHA256 of the body, computed with the subscription secret issued once at creation. If your endpoint is unavailable, delivery is retried up to 5 times with increasing intervals. Verify the signature before processing.

Keep the secret server-side; your front end should never hold it. Operating rules and each party's responsibilities are set out in the terms of use.

How to Connect

The full specification for the crypto exchanger API is published in machine-readable form at eidex.io/merchant-openapi.json and imports directly into Postman, Insomnia or a client generator. The fastest path is the quickstart guide: issue keys, verify `GET /tickers`, then build your first test order.