How to Design a Custom Market Connector for Barfinex
A practical guide to connecting an exchange, broker, or data source to Barfinex through Provider contracts, normalized data, and permissioned integration surfaces.
Your Market Source, Standard Barfinex Contracts
Every trading team eventually has a source that is not covered by a default catalog: a regional broker, a specialist market-data vendor, an OTC desk, an internal pricing feed, or an exchange with unusual rules.
The point of a Barfinex connector is to translate that source into standard Provider contracts. Once the data is normalized, the rest of the system can work with it through familiar surfaces instead of custom one-off code.
What a Connector Does
A connector is the bridge between Barfinex and an external exchange, broker, or data source. It handles the source-specific API and returns data in the shape Barfinex expects.
Depending on what your deployment allows, a connector can expose:
- Market data for Detector strategies: trades, order books, candles, instruments, and quotes.
- Approved account context for risk and portfolio views.
- Permissioned execution intents only when the deployment, credentials, and risk controls explicitly support them.
- Studio visibility so operators can inspect the source with the same interface used for other venues.
- Approved AI-assistant queries through MCP-style tools where the deployment has exposed read-safe data surfaces.
The principle is simple: implement once, expose through standard contracts, and keep source-specific complexity inside the connector boundary.
The Core Interfaces
Barfinex connectors are designed around a plugin model. A typical package separates connection lifecycle, streaming, adapters, and optional account or execution surfaces.
| Interface | Purpose |
|---|---|
| Client service | Manages authentication, readiness checks, rate limits, and connection state |
| WebSocket manager | Streams trades, order book updates, candles, and other approved channels |
| Market API | Lists instruments and fetches reference market data |
| Account API | Reads balances or positions where credentials and policy allow it |
| Execution API | Handles permissioned execution intents only for deployments that enable them |
| Data adapters | Normalize raw exchange messages into Barfinex models |
Provider loads connector packages through its configured plugin system, so core services do not need source-specific code.
What You Need Before You Build
Before writing code, clarify the integration scope:
- Which markets, symbols, and timeframes must be supported?
- Which channels are read-only market data, and which require private credentials?
- Does the connector need account context, or is market data enough?
- Are execution surfaces out of scope, simulated only, or explicitly permissioned?
- How will you test rate limits, reconnects, stale data, and schema changes?
This scope matters more than speed. A data-only connector can be straightforward; account and execution paths require more review, audit logging, and risk testing.
A Practical Build Path
Start narrow:
- Implement the client service and health checks.
- Add market metadata and instrument mapping.
- Normalize trades, candles, and order book updates.
- Validate reconnect behavior and gap handling.
- Register the connector in Provider.
- Inspect the source in Studio.
- Add account or execution surfaces only after the data path is stable.
That order keeps the first version useful without mixing market-data reliability with private-account complexity.
Who Benefits
Trading research teams can bring a niche venue or proprietary feed into the same signal pipeline as public markets.
Regional brokers and exchanges can make their APIs easier to evaluate through normalized Provider contracts.
Data vendors can expose alternative data, on-chain metrics, sentiment scores, or fundamental datasets as first-class market context.
Open-source contributors can add missing sources without changing Barfinex core services.
Connector Categories
The connector model is intended to cover several families of sources:
- Crypto and digital-asset venues.
- Broker APIs and execution management systems.
- FX, futures, and derivatives data.
- Market-data vendors.
- Alternative data providers.
- Internal research or pricing feeds.
The available catalog depends on the deployment and the current Provider package set. Studio should be treated as the operator-facing place to inspect what is enabled.
Start With the Full Guide
The detailed documentation covers package structure, TypeScript interfaces, adapters, Provider registration, tests, and publication flow.
Read the custom connector documentation
The Standardization Advantage
A good connector is not just an API wrapper. It turns a source into a governed Barfinex surface:
- Detector receives normalized data.
- Advisor can verify only the signed Provider evidence referenced by an immutable Detector candidate.
- Inspector can evaluate risk state where account data is approved.
- Studio gives operators one place to inspect health and behavior.
- Historical analysis can use the deployment-owned data layer.
That is the value of the connector boundary: source-specific complexity stays contained, and the rest of the platform can reason about data, signals, and risk consistently.
