High Availability Setup for REST API

Overview

The Currencies real-time REST API supports GeoDNS and regional endpoints. Customers can use these endpoints to build a more resilient request-based setup for current exchange rates and metadata.

Default real-time REST GeoDNS endpoint:

https://api-realtime.fx.finfeedapi.com/v1/

Regional real-time REST endpoints:

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

A high availability setup helps reduce dependency on a single endpoint or region. This is useful for customers who do not have dedicated infrastructure. Dedicated infrastructure is available only on Enterprise plans.

What it is

A REST high availability setup means configuring the customer application to use more than one real-time REST endpoint.

For example:

Primary endpoint:
https://api-realtime-emea.fx.finfeedapi.com/v1/

Secondary endpoint:
https://api-realtime-ncsa.fx.finfeedapi.com/v1/

If the primary endpoint becomes unavailable or degraded, the customer application can route requests to the secondary endpoint.

Why do it

This setup can help customers:

• Improve resilience against regional connectivity issues.
• Reduce dependency on a single routing path.
• Maintain request availability during endpoint degradation.
• Have better control over failover behavior for real-time rate lookups.

GeoDNS is suitable for general routing, while regional endpoints are useful when the customer wants explicit regional control.

How to do it

Step 1: Choose primary and secondary endpoints

Example using two explicit regions:

Primary:
https://api-realtime-emea.fx.finfeedapi.com/v1/

Secondary:
https://api-realtime-ncsa.fx.finfeedapi.com/v1/

Customers may also use GeoDNS as the primary endpoint and a regional endpoint as fallback:

Primary:
https://api-realtime.fx.finfeedapi.com/v1/

Secondary:
https://api-realtime-emea.fx.finfeedapi.com/v1/

Step 2: Add request health checks

The customer application should monitor:

• HTTP response status
• Timeouts
• Repeated errors
• Latency
• Regional endpoint availability

Example failover condition:

If the primary endpoint times out or returns repeated errors,
route the request to the secondary endpoint.

For exchange rate requests, a lightweight health check such as GET /v1/exchangerate/BTC/USD can be used to verify endpoint availability without requesting large payloads.

Step 3: Choose Active/Active or Active/Passive

Active/Active

In an Active/Active setup, the customer operates more than one active application path at the same time.

Example:

Application Server A -> https://api-realtime-emea.fx.finfeedapi.com/v1/
Application Server B -> https://api-realtime-ncsa.fx.finfeedapi.com/v1/

This setup usually requires customer-side active/active infrastructure as well, such as multiple application servers, independent routing, separate monitoring, and internal traffic management.

The exact implementation depends on the customer's own infrastructure and failover design.

Active/Passive

In an Active/Passive setup, the customer uses one primary endpoint and keeps another endpoint configured as fallback.

Example:

Primary:
https://api-realtime-emea.fx.finfeedapi.com/v1/

Standby:
https://api-realtime-ncsa.fx.finfeedapi.com/v1/

The standby endpoint is only used if the primary endpoint has an issue.

This can reduce duplicated usage compared with Active/Active, but failover may take longer.

Customer-side Active/Active setup

High availability is not only about using multiple FinFeedAPI endpoints. For an Active/Active setup, customers should also design independent active infrastructure on their side.

A common pattern is:

Customer Server A -> FinFeedAPI Region A
Customer Server B -> FinFeedAPI Region B
Customer internal routing -> Chooses the active application path
Customer monitoring -> Decides when to switch traffic

The exact design can vary depending on the customer's server architecture, internal routing, monitoring, downstream systems, and recovery procedures.

Billing impact

Using multiple endpoints can increase billable usage, especially if requests are duplicated across regions.

Active/Active setups may cost more because more than one path may be active at the same time.

Active/Passive setups may help reduce cost because the secondary endpoint is only used during failover.

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 requested.

Summary

For Currencies real-time REST API high availability:

• Use https://api-realtime.fx.finfeedapi.com/v1/ for GeoDNS routing.
• Use regional endpoints for explicit regional control.
• Use Active/Active when availability is the main priority and customer-side infrastructure supports it.
• Use Active/Passive when cost control is preferred and short failover time is acceptable.
• Monitor response status, errors, timeouts, and latency.
• Route traffic between internal customer servers or application paths based on the customer's own failover design.

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/