High Availability Setup for WebSocket API

Overview

The Currencies WebSocket API supports GeoDNS and regional endpoints.

Default WebSocket GeoDNS endpoint:

wss://api-realtime.fx.finfeedapi.com

Regional WebSocket endpoints:

wss://api-realtime-emea.fx.finfeedapi.com
wss://api-realtime-apac.fx.finfeedapi.com
wss://api-realtime-ncsa.fx.finfeedapi.com

Customers can use these endpoints to build a more resilient real-time exchange rate streaming setup.

What it is

A WebSocket high availability setup means connecting to more than one WebSocket endpoint or region.

Example:

Primary feed:
wss://api-realtime-emea.fx.finfeedapi.com

Secondary feed:
wss://api-realtime-ncsa.fx.finfeedapi.com

This allows the customer to maintain another path for real-time exchange rate data if one region or connection becomes degraded.

Why do it

This setup can help customers:

• Improve resilience for real-time exchange rate streaming.
• Reduce dependency on a single WebSocket endpoint.
• Have a backup path during regional or network issues.
• Control how failover works inside their own infrastructure.

How to do it

Step 1: Choose primary and secondary WebSocket endpoints

Example using two explicit regions:

Primary:
wss://api-realtime-emea.fx.finfeedapi.com

Secondary:
wss://api-realtime-ncsa.fx.finfeedapi.com

Example using GeoDNS plus regional fallback:

Primary:
wss://api-realtime.fx.finfeedapi.com

Secondary:
wss://api-realtime-emea.fx.finfeedapi.com

Step 2: Subscribe to the required exchange rates

After establishing each connection, send a hello or subscribe message with the same asset filters on each feed.

Example:

{
  "type": "hello",
  "apikey": "YOUR_API_KEY",
  "heartbeat": true,
  "subscribe_filter_asset_id": ["BTC/USD", "EUR/USD"]
}

The subscription should match the customer's use case. Use the same filters on primary and secondary connections to allow transparent failover between feeds.

Step 3: Add connection health checks

The customer application should monitor each connection independently.

Recommended checks:

• Connection state
• Heartbeat availability
• Time since last received exrate message
• Reconnect count
• Latency
• Unexpected message gaps
• Error responses or disconnects
• reconnect messages from the server

Example failover condition:

If no valid exrate message is received from the primary feed for a defined period,
route internal processing to the secondary feed or secondary application path.

When a reconnect message is received, consider establishing a secondary connection before the primary is closed, as described in the Messages documentation.

Step 4: Add customer-side Active/Active infrastructure

For WebSocket streaming, high availability should be handled at the customer infrastructure level.

In an Active/Active setup, customers should not rely on a single server consuming and merging multiple feeds. Instead, they should operate independent active paths on their side.

Example:

Server A -> wss://api-realtime-emea.fx.finfeedapi.com
Server B -> wss://api-realtime-ncsa.fx.finfeedapi.com

Each server can process its assigned feed independently. The customer's internal routing, downstream services, or application layer should decide which server or processing path is used during normal operation and during failover.

This design is company-specific and may depend on:

• Customer server architecture
• Internal load balancers
• Failover rules
• Monitoring systems
• Downstream consumers
• Data processing requirements
• Recovery procedures

Active/Active exchange rate consumption is most effective when the customer also has active/active hardware or server infrastructure on their side.

Active/Passive option

Active/Passive is also viable.

Example:

Primary:
wss://api-realtime-emea.fx.finfeedapi.com

Standby:
wss://api-realtime-ncsa.fx.finfeedapi.com

The secondary feed does not need to be fully active at all times. It can be activated only when there is an issue with the primary feed.

This may reduce duplicated usage, but failover may not be immediate because the standby connection may need to connect and subscribe before processing resumes.

Billing impact

Using multiple WebSocket feeds can increase billable usage because the customer may receive data from more than one connection.

Active/Active usually costs more because multiple feeds are active at the same time.

Active/Passive may reduce cost because the secondary feed is used only when needed.

Under Pay As You Go, higher usage may be billed at lower effective rates as customers move into higher usage tiers, but total cost can still increase if more data is consumed.

Summary

For Currencies WebSocket API high availability:

• Use wss://api-realtime.fx.finfeedapi.com for GeoDNS routing.
• Use regional endpoints for explicit regional control.
• Use two or more regions for better resilience.
• Use Active/Active only when the customer also has independent active infrastructure on their side.
• Use Active/Passive when cost control is preferred and a short failover delay is acceptable.
• Monitor connection state, heartbeat, exrate message flow, reconnects, and latency.
• Handle server switching and failover inside the customer's own infrastructure.

For customers who require dedicated infrastructure, custom deployment architecture, or stricter enterprise-grade availability planning, please contact our Sales Team to discuss Enterprise plan options.

We also recommend subscribing to the API Bricks status page for updates about incidents, maintenance, and service status changes:

https://status.apibricks.io/