How to evaluate a FIX API before committing your integration

"We support FIX 4.4 and 5.0" says nothing. It's like saying a car has wheels. What determines whether an integration will work are much less glamorous things: which messages they cover, what happens when the session drops, and whether the sandbox behaves like production.

This is the list your technical team should review before committing weeks of work.

What the version doesn't tell you

FIX is a protocol, not an implementation. Two venues that claim to support 4.4 can differ in:

Which message types they implement and which they ignore
Which tags are mandatory in each message
How they handle custom fields
Which rejection codes they return and what they mean
How they manage sequence numbering after a disconnection

None of those differences appears in "FIX 4.4." All of them appear in certification, which is when you've already invested time.

The message documentation should be available before you sign anything. If they give it to you only after the contract, you're buying blind.

Message coverage: what to ask

At a minimum, you need clarity on four flows:

Quoting. Streaming prices or request/response? Subscription per instrument or per list? What depth do they send and how often?

Order entry. Which types do they support — market, limit, stop, IOC, FOK? Modify and cancel orders? What's the behavior when a modification of an already partially filled order is rejected?

Execution reports. Do they send partial fills? At what granularity? How is the relationship between the original order and its fills identified?

Drop-copy. Is there a separate session that replicates your activity for reconciliation and compliance? For funds and firms with reporting obligations, it isn't optional.

Ask for this: the complete specification of messages and tags, including rejection codes, before certification.

Reconnection behavior, which is where everything breaks

This is the part that separates an integration that survives from one that wakes you up at dawn.

The specific questions:

What happens to in-flight orders when the session drops? Are they cancelled automatically, do they stay live, or does it depend on the configuration? All three answers are defensible; not knowing which is yours is not.

How is the sequence reset handled? When you reconnect, do they expect you to resume numbering where you left off, restart it, or negotiate? A mishandled sequence mismatch can block the entire session.

Is there recovery of lost messages? If you were disconnected for 30 seconds, can you request the messages from that interval or are they lost?

What's the heartbeat timeout and what happens when it's exceeded?

If any of these answers is "we'll see that in certification," take it as information: it means it isn't documented.

Symbol mapping: tedious and critical

Each venue names its instruments its own way. Gold can be XAUUSD, GOLD or XAU/USD, with differences in contract size, number of digits and session hours.

The mapping of your full catalogue should be agreed before certification, not during. It's the most common cause of delays, and it's completely avoidable.

Points that usually bite:

Instruments with the same name and different contract size
Differences in the number of decimals, which break pip calculations
Session hours that don't match what your platform expects
Instruments that exist in your catalogue and not in theirs

Ask for this: the agreed mapping of your entire catalogue, not a representative sample.

The sandbox: the only test that counts

A sandbox that doesn't behave like production pushes bug discovery into your first live session. It's the difference between a test environment and a stage set.

Production parity means specifically:

The same message types and the same rejection codes
Realistic rejection behavior, not universal acceptance
Representative latency, not instantaneous
The same session hours and the same instrument rules

And critically: credentials before the commercial commitment. A venue that asks you to sign to get sandbox access has inverted the correct order.

What you should test there:

The full order lifecycle: send, partial fill, full fill, cancel
A forced disconnection in the middle of a live order
A sequence reset
Rejections: provoke them deliberately and verify the codes are the documented ones
Your complete instrument catalogue
Behavior during a simulated high-volatility window

How long certification should take

With onboarding complete and the mapping agreed, days, not weeks.

What stretches the timelines is almost never the technology: it's the waiting. That's why it's worth having a named technical contact on your side from the start, with decision-making authority, instead of a chain of approvals.

If a venue quotes you a certification timeline of several weeks without explaining what justifies it, ask which part of the process is the slow one. The answer tells you a lot about what the operational relationship will be like afterward.

When FIX isn't the answer

It's worth saying, because there's a tendency to assume FIX is always superior:

If you run a MetaTrader brokerage with retail or professional clients on that platform, the MT5 bridge is the right path. FIX would add complexity without benefit.

If your stack is HTTP-first and modern — typical in recent prop firms and crypto-adjacent venues — REST plus a low-latency WebSocket with OpenAPI documentation can be a better fit than FIX, and considerably faster to integrate.

FIX is the path when your OMS or EMS speaks it natively, when you need drop-copy for compliance, or when volume and latency justify the integration investment.

Many firms start with the bridge and add FIX as they scale. It's a sensible progression, not a defeat.

Frequently asked questions

Is FIX 5.0 better than 4.4? Not for most cases. 4.4 is still the de facto standard in institutional FX and is better supported across the whole chain. 5.0 introduces structural improvements, but if your counterparty and your OMS speak 4.4 without trouble, there's no reason to complicate things.

Do I need drop-copy? If you have reporting obligations, a fund administrator that must reconcile, or auditors who'll ask for traceability, yes. If you're a small broker without those obligations, it's a luxury. Ask anyway whether it's available: that it exists says something about the venue's maturity.

Can I use my own FIX engine? Usually yes, and it's the norm. What you need to verify is that your engine and their implementation match on the details that matter — above all sequence handling and custom fields.

What do I do if the sandbox doesn't have production parity? Ask for it explicitly. If the answer is that they don't have it, it's a relevant data point about what going into production will be like, and you should budget stabilization time you hadn't planned for.

The technical detail of our implementation is in FIX API: sessions, message coverage, production-parity sandbox and reconnection behavior documented before certification. Clients onboard and execute through us; sandbox credentials are issued before any commercial commitment.

For the general framework: how a broker chooses liquidity.