Skip to content
Docs
Developers

Integration overview

Connect to market data, manage orders and build account-aware applications with REST, WebSockets and MCP.

Choose your integration surface

Use REST for market discovery, initial snapshots, history and order commands. Use WebSockets for live market and account updates. MCP gives AI clients access to tools backed by the same REST operations. Market-making clients can connect directly through REST and WebSockets.

Start with public market reads in your chosen environment. Add an account-scoped credential when you need private data or trading access. Edel Markets supports perpetuals; spot trading is not offered.

Choose the client surface

100%
Diagram preview

Drag to pan, or use arrow keys when the diagram is focused. Use plus and minus to zoom, and zero to fit. On a touch screen, pinch to zoom.

Optional MCP wraps REST capabilities while WebSockets supply continuous updates.
SurfaceUse it forAuthentication
REST /v1Market catalogue, snapshots, history, previews and ordersPublic market reads need none; private routes require the permitted bearer
WebSocket /streams/v1/wsBooks, trades, prices and account updatesPublic channels need none; private channels use a short-lived ticket
Remote MCP /mcpAgent tools backed by RESTOwner-approved API key on every request, including market tools
CCXT /v2Published CCXT-compatible operationsSee each route; unsupported methods explicitly return 501

Make a public read

Set EDEL_API_URL to your Devnet REST base URL from environments and endpoints. This public catalogue request requires no credentials. The documentation host serves the API reference, not venue requests.

Use the returned market IDs, scales, bounds, status and fees to configure your client. After the initial read, subscribe to the relevant WebSocket channels for live market updates.

Public catalogue request
curl --fail-with-body --silent --show-error \
  "$EDEL_API_URL/v1/markets"

Build from the published contracts

Build with the published REST OpenAPI and product AsyncAPI schemas. The REST schema documents request and response shapes; the AsyncAPI schema defines market and account channels, their messages and payload types. Check each operation’s credential requirements and each channel’s availability before integrating.

Use the REST and realtime API references alongside these schemas. Generate your client from a contract compatible with the target environment. Types help validate requests and data; they do not grant route access or establish that a capability is enabled.

Connect snapshots, commands and live updates

  • 01Read market metadata and the relevant initial snapshots.
  • 02Connect a WebSocket and subscribe to the channels your application needs. Match each subscription acceptance by requestId.
  • 03Validate incoming messages and apply them directly to shared market and account state. Track current state separately from historical records.
  • 04Submit authorized commands through REST. Preserve each command’s identity until its outcome is known, and confirm fills and position changes through account streams.
  • 05If continuity is lost, mark the affected state stale and follow the channel’s documented recovery process.

Use stream payloads to keep live views current. Repeated REST or MCP snapshots, including a REST refetch after every WebSocket event, cannot provide the same event continuity. If a channel lacks a required field, show that view as snapshot-only or unavailable.

History pagination, authentication, ticket rotation and documented recovery use their own bounded request workflows. Webhooks are not part of the public API. Continue with WebSockets, account streams and order commands.

Supported order and integration features

The /v1 API supports limit and market orders, post-only limits, reduce-only orders and attached take-profit/stop-loss prices. Market orders use IOC behavior and limit orders use GTC behavior. There is no public timeInForce field, standalone trigger-management route or amend-order endpoint. A cancel followed by a replacement order is two separate commands; the original order can still fill while cancellation is pending.

The API reference lists the supported CCXT-compatible methods. Unsupported methods return HTTP 501 NotSupported. REST and WebSockets are the public integration interfaces. FIX is not included in the public API; any FIX integration would require a separate supported contract from Edel.

Core integration concepts

Bootstrap loads the initial snapshot for an account, market or other selected scope. Subscription acceptance confirms that the requested stream is active. Continuity means the sequence and replay information is sufficient to apply subsequent messages safely.

Command feedback reports the submitted instruction’s outcome. Fill evidence records execution, while Canton confirmation establishes settlement. Keep these stages separate in your application.

Scope includes the environment, account, market and channel. Reset or isolate state when that identity changes so a delayed response for one account cannot overwrite another. See the glossary for trading terms and account streams for the data model.

Environment and availability

Edel Markets is running on Devnet. Testnet and Mainnet are coming soon. Use the environment reference to keep endpoints, credentials, account identifiers and market metadata together.

Security audits have not yet been completed. See audit status. Before enabling trading, check schema compatibility, account readiness and live subscription health. Find request fields in the REST API reference and the place-order operation.