Regions & Endpoints

FalconQ infrastructure is served from Frankfurt, with HTTP traffic fronted by a global edge network for fast TLS termination wherever you are.

Service	Endpoint	Notes
HTTP RPC	https://api.falconq.xyz/v1/rpc	Global edge in front, served from Frankfurt
WebSocket	wss://api.falconq.xyz/v1/ws	Same host as HTTP RPC
REST	https://api.falconq.xyz/sol/v1	Shyft-compatible REST API
gRPC / FalconStream	grpc.falconq.xyz:50051	Direct connection — no edge proxy, lowest latency

Current Region

All requests are currently served from Frankfurt (FRA) — the optimal location for European trading infrastructure and a strong default for global workloads thanks to its proximity to major Solana RPC infrastructure. Additional regions (New York, Singapore) are planned.

Every RPC response includes an x-proxy-region header identifying the region that served it, so region-aware code you write today will keep working as new regions come online.

Measuring Your Latency

Response headers break down where time is spent on every request, so you can separate network latency from processing time:

curl -s -D - -o /dev/null -X POST https://api.falconq.xyz/v1/rpc \
  -H "Authorization: Bearer fq_rpc_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'

# Response headers:
# x-proxy-region: fra        <- region that served the request
# x-proxy-latency: 2         <- ms spent inside the FalconQ proxy
# x-upstream-latency: 38     <- ms spent waiting on the Solana upstream

If total request time is much higher than x-proxy-latency + x-upstream-latency, the difference is network distance between you and the region — for latency-critical bots, host your workload close to Frankfurt.