Crypto Exchanger API: Quotes, Orders and Deposit Addresses

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.