Coiny's APIs provide REST and WebSocket access to trading, market data, and strategy connectivity, with SDKs, webhooks, authentication, rate limits, and a test environment provisioned during integration. Every endpoint your exchange runs on is an endpoint your engineers can call — the same matching engine, the same accounts, the same market data — under keys you scope, allowlist and revoke yourself.
Request and response for orders, balances, transfers and reference data. Streaming sockets for order books, trades, tickers and your own private order and fill events.
Comprehensive REST, WebSocket and CCXT SDK support with documentation, so a desk already trading through CCXT points the same client at your venue and keeps its code.
Deposits, fills, verification results and settlement are pushed to your endpoint, signed and sequenced, so your services stop polling for things that have already happened.
Read, trade and transfer are separate grants. Every key carries an IP allowlist and a rate-limit band, and revoking one takes effect on the next request.
There is no second-class API here. The platform's own trading screens, mobile apps and admin console call the same endpoints your integration will, which is why the surface is complete rather than a subset published for partners.
Place, amend and cancel orders; read positions, balances, transfers, deposits and withdrawals; pull the reference data that tells you what a market allows — symbols, tick sizes, fee tiers and order limits. Requests are idempotent on your own client order id, so a retry after a timeout cannot double-fill a position.
Authentication and rate control are not per-endpoint decisions bolted on later. They sit in front of the whole surface, which is why a scope granted on a key means the same thing whether the call arrives over REST, a socket or a FIX session.
These are the four shapes an integration usually takes. Each one is a different combination of the same surfaces, and each has a deeper product page behind it.
Order entry over REST, live books and fills over the socket, and a scoped key per bot so a strategy that misbehaves is revoked on its own.
Read-only keys feed your accounting, reconciliation and CRM systems, and webhooks push deposits, withdrawals and settlement state as they happen rather than on a nightly export.
Pull historical and live market data for research, then deploy an approved strategy through the same authenticated endpoints that carry its fills back.
Desks whose order management system already speaks FIX 4.4 connect over a session rather than an HTTP client. Trading platform bridges and liquidity, payment and compliance providers are catalogued separately.
The three questions a technical evaluator opens this page with, answered in one table: what can I call, how do I prove who I am, and what happens when my integration gets busy. The short version is that authentication and limits are per key on every surface — nothing here is enforced at the account level.
| # | Surface | What it carries | Authentication | Limits and controls |
|---|---|---|---|---|
| 1 | REST API | Orders, balances, transfers, deposits, withdrawals and reference dataidempotent on your client order id | API key, timestamp and request signature, sent as headers | Per-key rate-limit band, scoped permissions, optional IP allowlist |
| 2 | WebSocket — public | Order book deltas, trades, tickers and candlessubscribe per instrument and channel | None — public market data | Connection and subscription limits per client |
| 3 | WebSocket — private | Your own order updates, fills and balance changesthe same events, pushed instead of polled | The same key as REST, authenticated on connect | Scoped to that key: a read-only key can watch, never send |
| 4 | Webhooks | Deposits, withdrawals, fills, verification results and settlementsequenced, and replayable from the delivery log | Signed payload your endpoint verifies before acting | Retried with backoff until your endpoint acknowledges |
| 5 | FIX 4.4 | Institutional order flow and market data over a sessionfor desks whose OMS already speaks FIX | Session logon with credentials issued per counterparty | Session-level throttling and permissioned message types |
| 6 | Test environment | The same four surfaces, against isolated dataprovisioned as part of your integration | Separate keys that resolve only in that environment | No flag promotes a test key into production |
Three screens cover most of what an engineering team needs to see before committing: how a call is authenticated and what comes back, how permissions are cut per key, and what happens to an event when your endpoint is having a bad afternoon.
The questions that decide whether a platform is buildable-on, answered plainly. If yours is not here, an integration engineer will answer it directly rather than pointing you at a form.
This page covers what you build against. Which third-party systems Coiny connects to, the research infrastructure behind the strategy endpoints, and the agent-facing layer above them all live on their own pages.
Coiny Exchange provides a full developer API surface: a REST API for orders, balances, transfers and reference data, a WebSocket API for streaming market data and private order events, signed webhooks, and FIX 4.4 session connectivity for institutional desks. Testing is handled through an isolated test environment provisioned as part of your integration rather than a public self-service sandbox, with its own keys that resolve only there. Ask for API access and test credentials when you book a technical walkthrough.
A crypto exchange API is the programmatic interface through which software places orders, reads market data and manages accounts on a digital-asset trading venue, without a human using the trading screen. Coiny Exchange exposes that interface across four surfaces: REST for request-and-response operations, WebSocket for streaming data and private order events, webhooks for events the platform pushes to you, and FIX 4.4 for institutional order flow. All four are governed by the same keys, scopes and limits.
Authentication on the Coiny Exchange API uses an API key and secret issued per integration. Private requests carry the key, a timestamp and a signature in headers, never in the query string, and the same key authenticates the private WebSocket channels. Each key is scoped separately for read, trade and transfer, carries an optional IP allowlist enforced at the gateway, and can be rotated or revoked on its own without disturbing any other integration.
The REST API answers a question you ask; the WebSocket API tells you when something changes. On Coiny Exchange you place, amend and cancel orders and read balances, transfers and reference data over REST, then subscribe over WebSocket to order book deltas, trades, tickers and candles, plus your own order updates, fills and balance changes on an authenticated channel. Production integrations use both: REST to act, sockets to stay current without polling.
Rate limits on Coiny Exchange are applied per API key rather than per account, so one busy integration cannot starve another. Each key is issued in a limit band that suits what it does — a market-making engine and a nightly reporting job do not need the same headroom — and the band is set for your deployment during integration. A key that exceeds its band is throttled and told so in the response rather than being disconnected mid-session.
Coiny Exchange ships comprehensive REST, WebSocket and CCXT SDK support with documentation. CCXT is the industry-standard crypto trading library, so a team already running strategies through it points the same client at your venue and keeps its existing code: request signing, timestamps and reconnection are handled by the library rather than written again. Teams that prefer to call the endpoints directly work from the same documented request and response shapes.
Webhooks invert the direction of the integration: instead of your service polling Coiny Exchange for changes, the platform posts events to an HTTPS endpoint you register. Deposits confirmed, withdrawals changing state, orders filled, identity verification results and settlement completions each arrive as a signed, sequenced payload. Verify the signature before acting on it, and replay any delivery from the log while you are still building against it.
Bring your architect and your integration lead. We will walk the REST and WebSocket surfaces, the webhook event catalogue, the key and scope model and the rate-limit bands against your actual use case, and provision a test environment so your team can start building before the platform is live.
Book a Demo
