A market-making platform doesn't operate on a single exchange or depend on one data source. It continuously receives market updates, evaluates prices, calculates quotes, checks risk limits, and sends orders to trading venues.
The challenge becomes more complicated when a trading firm connects to multiple exchanges. Each venue may have different API specifications, market-data formats, rate limits, order types, and execution rules. The platform needs to handle these differences without allowing one connection failure or delayed data feed to disrupt the entire trading operation.
This is why market-making software integration involves much more than connecting an API. It requires a coordinated architecture in which market data, trading strategies, risk controls, order management, and exchange connectivity work together.
This article explains how these components connect, where integration problems typically occur, and what development teams need to consider when building a multi-exchange market-making platform.
Before connecting individual APIs, it's important to understand how information moves through a market-making platform.
A simplified architecture looks like this:
Exchange APIs → Market Data Layer → Normalization Engine → Strategy Engine → Risk Management → Order Management System → Execution Gateway → Exchanges
Each component has a specific responsibility.
For example, a market-making strategy may calculate a new bid and ask based on the latest order book. Before those quotes reach an exchange, the platform needs to validate their prices and quantities, check available inventory, and determine which venue should receive each order.
If these components operate independently without a reliable integration layer, the platform can act on outdated information or lose track of orders. The objective of market-making platform development should therefore be to establish a consistent flow of information and execution across the entire system.
Market data is the foundation of a market-making strategy. The platform needs an accurate view of prices, available liquidity, order book depth, and recent trades to calculate competitive quotes. Most exchanges provide market data through REST APIs and WebSocket connections, although the available interfaces and capabilities vary.
REST APIs are useful for retrieving snapshots, account information, and historical records. WebSocket connections are generally more suitable for continuous market updates because they maintain a persistent connection and deliver events as they occur.
For example, Coinbase Exchange provides WebSocket channels for ticker updates, order book information, and trade matches. Its Level 2 channel delivers order book updates that can be used to maintain a local view of market depth.
However, receiving data is only the first step. The platform must also maintain an accurate order book.
Consider a strategy monitoring BTC/USDT across two exchanges. One exchange reports a best bid of $67,000, while another reports $67,015. The strategy may identify an opportunity to quote between those prices. But if one feed is delayed, the apparent price difference may no longer exist. Acting on it could result in an uncompetitive quote or an unexpected execution.
A reliable market-data integration should account for:
The system should also identify stale market data. If an exchange feed stops updating, the strategy shouldn't continue treating the last received price as current. This makes real-time market data integration a data-quality problem as much as a connectivity problem.
Different exchanges may provide similar information in different formats. One venue might represent an order status as PARTIALLY_FILLED, while another uses a different event structure. Price precision, quantity increments, timestamps, and order identifiers can also vary.
If the strategy needs separate logic for every exchange, adding another venue becomes increasingly complicated. A normalization layer solves this by converting exchange-specific messages into a common internal model.
For example, the platform can standardize:
The exchange adapter handles the differences between venue APIs, while the strategy and order management layers work with consistent internal structures. This separation is particularly useful when a firm adds exchanges, changes connectivity providers, or supports new asset classes.
The FIX Protocol is another important consideration for institutional trading integrations. Maintained by the FIX Trading Community, it defines standardized message structures and workflows for market data, order handling, and execution reporting. It is designed to remain independent of the underlying network transport.
The choice between FIX, REST, WebSocket, or a venue-specific protocol depends on the exchange, trading requirements, and available connectivity.
Receiving market data and placing orders are separate responsibilities. A platform needs a reliable way to submit orders, receive acknowledgements, track fills, and handle cancellations. Trading APIs commonly support operations such as:
The execution gateway should translate internal order instructions into the format required by each exchange. For example, a strategy may generate an instruction to place a limit buy order for a particular quantity at a specified price. The gateway validates the venue-specific requirements, sends the request, and processes the exchange's response.
However, sending an order doesn't mean it has been accepted or executed. Consider this sequence:
If the platform blindly resends the request, it could create a duplicate order. A better design uses unique client order identifiers, tracks request status, and reconciles uncertain orders with the exchange before retrying.
The same applies to cancellation. A cancel request doesn't guarantee that an order has been cancelled. It may have filled or partially filled before the exchange processed the cancellation. This is why trading API integration must include order-state management, not just request submission.
Connecting multiple exchanges introduces more than additional API endpoints. Each venue has its own rules covering order types, price and quantity increments, rate limits, authentication, connection management, and execution responses.
These differences need to be handled by individual exchange adapters without changing the strategy's core logic.
For example, Binance's official Spot WebSocket documentation specifies that a connection is valid for 24 hours, sends ping frames every 20 seconds, and supports up to 1,024 streams per connection. It also documents incoming-message limits and connection restrictions.
These are not universal WebSocket rules. They are Binance-specific requirements that an integration needs to accommodate.
Similarly, Binance's REST API documentation explains that exceeding request limits can trigger HTTP 429 responses. Repeated violations without backing off can lead to HTTP 418 IP bans.
For a market-making platform, these details have practical consequences. If the system repeatedly requests account or order information without considering rate limits, it may lose access to important API operations. If a WebSocket connection reaches its scheduled disconnection, the platform needs to reconnect and restore its market-data state.
A robust multi-exchange architecture should therefore include:
The strategy should not need to understand every exchange's connection rules. The connectivity layer should manage those differences.
One of the most important integration challenges is maintaining a consistent view of the trading operation. The strategy may calculate a quote using current market data, but the risk engine also needs accurate information about open orders, filled quantities, and available inventory.
Consider a market maker with a maximum permitted position of 10,000 units. Its current position is 9,500 units, and the strategy wants to place another buy order for 1,000 units. If the risk engine checks only the filled position and ignores the remaining quantity of open buy orders, it may approve an order that takes potential exposure beyond the limit. The system must account for both executed positions and outstanding orders when calculating exposure.
It also needs to process execution updates quickly. A partially filled order changes the firm's inventory and may require the strategy to adjust its quotes on one or more exchanges. A reliable architecture should connect:
Order submission → Exchange acknowledgement → Execution update → Position update → Risk recalculation → Quote adjustment
This flow should use consistent identifiers and timestamps so the team can trace an order from the original strategy decision through its final execution state. Without this connection, the strategy may continue quoting based on inventory that no longer reflects the firm's actual exposure.
Exchange connections can drop, market-data feeds can become delayed, and trading APIs can return incomplete responses. The platform needs to respond safely rather than simply attempt to reconnect and continue trading. Imagine a market-data connection drops while the strategy is running. The local order book stops receiving updates, but the strategy continues calculating quotes using the last available prices.
Those quotes may no longer reflect the actual market. A safer recovery sequence is:
Connection failure → Detect stale data → Pause affected quoting → Reconnect → Retrieve fresh market data → Reconcile open orders → Restore valid state → Resume trading
The recovery process should also distinguish between different failures.
A market-data connection failure may require the strategy to stop using that venue's prices. A trading API failure may require the system to verify open orders before attempting new submissions. A position mismatch may require reconciliation before trading resumes.
Multi-exchange connectivity should also support independent failure handling. If one venue becomes unavailable, the platform should be able to protect its exposure there without unnecessarily interrupting operations on healthy venues.
Before starting a market-making software integration project, define the requirements that influence the architecture.
These decisions help determine whether the platform needs simple API adapters or a more sophisticated connectivity and execution architecture.
Market-making platforms depend on several connected systems working together. A problem in market-data processing, exchange connectivity, or order-state management can affect the entire trading operation.
WebMob approaches market-making platform development by considering the complete integration flow, from exchange data ingestion and normalization to strategy connectivity, risk checks, order management, and execution.
The architecture is planned around the firm's trading model, supported exchanges, asset classes, expected message volumes, and operational requirements. This helps create a platform that can accommodate additional venues and trading requirements without making every new integration a separate engineering effort.
Connecting exchange APIs is only one part of building a market-making platform. The more important task is ensuring that market data, trading strategies, risk controls, and execution systems maintain a consistent view of the trading operation.
A well-designed integration architecture handles exchange-specific differences, detects stale data, manages order states, and recovers safely from connection failures.
For firms planning to expand across trading venues, getting these integration decisions right provides a stronger foundation for reliable execution and future platform development.
Market-making software integration involves connecting exchange APIs, market-data feeds, trading strategies, risk systems, and execution engines so a market-making platform can receive market information and manage orders across trading venues.
Real-time market data integration is important because market-making strategies rely on current prices, order book depth, and trade information to calculate quotes. Delayed or incomplete data can lead to inaccurate pricing and unexpected exposure.
The platform connects to individual exchange APIs through dedicated adapters. These adapters handle venue-specific protocols and convert incoming data and execution responses into a common internal format.
REST APIs use request-response communication and are commonly used for account queries, snapshots, and general operations. WebSocket connections provide continuous event streams and are commonly used for real-time market data and order updates.
Common challenges in trading API integration include inconsistent API formats, rate limits, authentication, connection interruptions, duplicate requests, uncertain order status, and differences in exchange execution rules.
The market-making platform should detect connection problems, stop relying on stale market data, protect affected orders, reconnect, retrieve fresh market information, reconcile open orders, and resume trading only when the relevant state is verified.
Let’s discuss and plan how we can accelerate your growth. Fill out this form and take the first step towards constant advancement.
We will respond to you within 24 hours.
Access to dedicated product specialists.
