DEVELOPERS AND INTEGRATIONS

Everything Your Engineers Can Build On, in One Place

Coiny's developer platform exposes the exchange stack through REST and WebSocket APIs, SDKs, FIX/MT5/cTrader connectivity, and AI-agent infrastructure. There are three surfaces, and the difference between them is who is doing the reaching.

Talk to an Engineer
3developer surfaces
FIX 4.4MT5 and cTrader
MCPfor AI agents
Scopedkeys and agents
PICK YOUR SURFACE

Connect To It, Build Against It, or Give an Agent Access

Three pages, three jobs. Each card below routes to the canonical page for that surface — its protocols, its controls, its limits and its own answers. Start from whatever has to reach the exchange.

CONNECT TO

Integration Catalogue

What a Coiny Exchange deployment connects out to. FIX 4.4 sessions for institutional order flow, MT5 and cTrader bridges that map crypto instruments into a broker's existing environment, liquidity providers and venues.

  • FIX 4.4, MT5 and cTrader trading connectivity
  • Liquidity, payment, KYC and AML, custody and support
  • Enabled and configured per deployment, by the operator
FIX 4.4MT5cTraderSumsubZendesk
Learn more
Integration catalogue showing FIX, MT5, cTrader and liquidity-provider connections
BUILD AGAINST

APIs, SDKs & Webhooks

What your own code calls. REST for orders, balances, transfers and reference data; WebSocket for order books, trades, tickers and your own private order and fill events.

  • REST and WebSocket over the same engine the platform runs on
  • Signed, sequenced webhooks with a replayable delivery log
  • Keys scoped by read, trade and transfer, with IP allowlists
RESTWebSocketWebhooksCCXTScoped keys
Learn more
A connectivity card listing a FIX 4.4 session and MT5 and cTrader bridges, beside REST and WebSocket endpoints
GIVE SAFE ACCESS

Intelligence Developer Platform

What a model or agent is allowed to reach. A trading harness hands the model a bounded set of tools and holds the credentials it never sees.

  • Trading harness that holds credentials the model never sees
  • MCP servers for market data, portfolio, research, risk and trading
  • Deny-by-default scopes, approval gates, kill switch and audit trail
MCPTrading harnessGuardrailsAudit trail
Learn more
An agent reaching the order book only through an enforced policy gate
THE STACK, LAYER BY LAYER

What Sits Under All Three Surfaces

The surfaces differ; what they reach does not. Connectivity, the exchange core, the permission model and the agent harness are four layers of one deployment, and a change at any layer applies to every surface above it.

Connectivity layer
PROTOCOL

Connectivity layer

The ways in and out. FIX 4.4 sessions carrying order entry and drop copy, MT5 and cTrader bridges with symbol mapping and hedged fills, REST and WebSocket endpoints for request and stream, and signed webhooks that push deposits, fills, verification results and settlement to your endpoint. Adding a protocol does not change the engine behind it.

1 of 4
HOW IT FITS TOGETHER

Three Surfaces, One Exchange Behind Them

Read it left to right: who is connecting, the surface they use, and the single deployment all three land on.

Diagram: venues, liquidity, payment, compliance and support systems connecting through the integration catalogue, engineering teams building against REST, WebSocket, webhook and FIX surfaces, and AI agents reaching the platform through the trading harness and MCP servers, all landing on one Coiny Exchange deployment

Venues and providers reach the platform through the integration catalogue; your engineers reach it through REST, WebSocket, webhooks and FIX 4.4; models and agents reach it through the trading harness and its MCP servers.

CHOOSE THE SURFACE

Which Surface Handles Which Job

The conclusion of the table below: pick by who is doing the reaching, not by what you want to accomplish. An outside system reaching in is an integration and is configured by the operator during deployment; your own code reaching in is an API call under a key you scope; a model reaching in is a harness call under permissions the platform enforces rather than the prompt.

#SurfaceThe question it answersWhat crosses itWho sets the limits
1IntegrationsThe integration catalogueWhat does the platform connect to?An outside system reaching inFIX 4.4, MT5 and cTrader order flowLiquidity, payments, KYC and AML, custody, supportThe operator, per deploymentNothing is reachable until it is switched on
2APIs, SDKs and webhooksThe developer surfaceWhat do we build against?Your own code reaching inOrders, balances, transfers, market dataREST and WebSocket in, signed webhooks outYour team, per keyRead, trade and transfer grants, allowlists, rate bands
3Trading harness and MCPThe intelligence surfaceWhat may an AI agent reach?A model reaching inTool calls against market data, portfolio, risk, tradingCredentials stay with the harness, never the modelThe platform, per agentDeny by default, approval gates and a kill switch
THE CONSOLES BEHIND EACH SURFACE

Where Each Surface Is Actually Configured

One screen from each of the three pages: where connections are enabled, where keys are scoped, and where an agent's tools are registered and gated.

The catalogue, and what is switched on Integrations

Every connection a deployment can make, with its status and the protocol behind it. Connectivity becomes something an operator reads off one screen rather than reconstructs from a deployment ticket.

  • FIX 4.4, MT5 and cTrader bridges with their session state
  • Liquidity providers and venues feeding aggregated books
  • Payment, identity and screening providers per market
  • Custody connections and support desk routing
Explore the integration catalogue
Integration catalogue showing FIX, MT5, cTrader and liquidity-provider connections
BEFORE YOU COMMIT

What Engineering Teams Ask While Evaluating the Platform

Extensibility is what a technical evaluation actually turns on. These are the questions that come up before anyone signs, answered without a sales layer in front of them.

  • Is the API a subset of what the platform itself uses?No. 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 partner-facing extract of it.
  • Can we test against something before we go live?Yes, in an isolated environment provisioned as part of your integration rather than a public self-service sandbox. It runs the same API surface, so what you build against it is what runs in production.
  • Do we have to replace the systems we already run?No. An MT5 or cTrader environment keeps its groups, symbols and reporting and gains crypto instruments through a bridge. Ledgers, reporting and support tooling read the platform over REST and receive state changes as signed webhooks.
  • How do we stop one credential from doing everything?Scope it. Read, trade and transfer are separate grants, each key carries an IP allowlist and a rate-limit band, and revoking a key takes effect on the next request rather than at the end of a session.
  • Can we let an AI agent trade without handing it the keys?Yes. The trading harness holds the credentials and the model never sees them. It calls tools, and every call is checked against its scope, the operator's limits and a pre-trade check before anything reaches the engine.
Talk to an Engineer
GO DEEPER

The Pages Behind Each Surface

The first three links are the canonical pages for the three surfaces. The rest are the platform areas engineering teams reach for next.

integration catalogue: FIX, MT5, cTrader & more

Everything a deployment connects out to: trading connectivity, liquidity providers and venues, payment and compliance providers, custody connections and support systems, configured per deployment.

exchange APIs, SDKs & webhooks

The surface your engineers build against: REST and WebSocket over the same engine the platform runs on, signed webhooks, SDK and CCXT support, and keys scoped by grant.

AI agent trading infrastructure

A trading harness, MCP connectivity, model orchestration and tool connectors, governed by deny-by-default permissions, pre-trade guardrails, approval gates and an exportable audit trail.

AI trading intelligence platform

The product layer the developer platform sits beneath: research, strategy, execution, portfolio, operations and compliance intelligence, running under operator-defined approvals.

liquidity provider connectivity

How aggregated depth reaches the order book, and which venue and provider connections a deployment can carry alongside its own matching engine.

backtesting infrastructure & strategy APIs

Research infrastructure for testing strategies on historical market data, including walk-forward and robustness analysis, deployed through the same authenticated surface.

COMMON QUESTIONS

FAQ

A digital asset developer platform is the set of programmable surfaces an exchange exposes so that other software can trade on it, read its data and operate it. Coiny's developer platform exposes the exchange stack through REST and WebSocket APIs, SDKs, FIX/MT5/cTrader connectivity, and AI-agent infrastructure. Three pages cover it: the integration catalogue for what the platform connects to, the API surface for what your engineers build against, and the Intelligence Developer Platform for what an AI agent is allowed to reach.

An integration is a connection the exchange makes outward to another system on the operator's behalf; an API is a surface your own code calls inward. Coiny Exchange configures integrations during deployment — liquidity providers, payment providers such as Paybis and Simplex, identity and screening providers such as Sumsub, custody providers, and support systems such as Zendesk. The REST, WebSocket, webhook and FIX 4.4 surfaces are what your engineers build against afterwards, under keys you scope and revoke yourself.

Yes. A Coiny Exchange deployment is not a closed product: the endpoints its own trading screens, mobile apps and admin console call are the endpoints your team calls. That covers order entry, balances, transfers, market data and reference data over REST and WebSocket, signed and sequenced webhooks for events you would otherwise poll for, and scoped keys that separate read, trade and transfer permissions from each other.

Start from what has to reach the exchange. If an existing system is doing the reaching — an MT5 or cTrader desk, a liquidity provider, a payment or KYC vendor — that is an integration, and it belongs in the Coiny Exchange integration catalogue. If your own application is doing the work, start with the REST and WebSocket APIs. If a model or an agent is acting, start with the Intelligence Developer Platform, where permissions and guardrails are enforced by the platform.

Yes. Integrations, APIs and the AI-agent trading harness all read and write one Coiny Exchange deployment: the same matching engine, the same ledger and balances, the same market and reference data, and the same audit log. An order arriving over FIX 4.4, an order placed over REST and an order an agent submits through the harness are the same order once they reach the engine, and they appear identically in reporting.

The operator does, at every layer of a Coiny Exchange deployment. Integrations are enabled per deployment, so a venue, payment or compliance provider is reachable only if it was switched on. API keys carry separate read, trade and transfer grants with IP allowlists and rate-limit bands, and revoking one takes effect on the next request. Agent access is deny-by-default per tool, venue, instrument and size, with approval gates and a kill switch enforced by the platform rather than by a prompt.

BRING YOUR STACK

Map Your Architecture Against the Platform

Bring what you already run — the trading platform, the venues and providers, the internal systems, the agents you want to give access to — and an engineer will walk it against the three surfaces on this page and tell you which one carries it.

Book a Demo