How to measure Binance API latency from your server

Where the matching engine actually sits

Every latency question about Binance reduces to one fact: the matching engine runs in Amazon's Tokyo region, ap-northeast-1. This isn't a secret — AWS's own engineering blog names Binance among the exchanges concentrated in Tokyo, and when the Tokyo region had its outage in October 2025, Binance and its neighbors went down with it. The server location question is therefore settled physics: your requests travel to Japan and back, and no amount of code optimization shortens the Pacific.

There's a subtlety that breaks naive measurements, though. The public API hostnames are fronted by a CDN, so the machine that answers your TCP handshake is the nearest edge node — possibly in your own city — while the actual work still happens in Tokyo. This is why ping api.binance.com returns flattering single- or double-digit numbers from anywhere in the world: you're timing the road to the edge, not the road to the engine. Any measurement that matters must time a complete API call, request to response.

Typical times from common regions

Honest numbers first, then how to get your own. From a server in Tokyo, a full REST round trip to the Spot API runs about 20–25 ms. From Singapore or Seoul you're in the 70–100 ms band. From the US, roughly 120–180 ms depending on the coast. From Europe, expect around 270 ms — Frankfurt to Tokyo and back is simply a quarter of a second of fiber, and that's before the exchange does any work. The round-trip latency you'll observe is dominated by that geography; everything else is decoration measured in single milliseconds.

Measuring your own number takes a dozen lines, with three rules that make the result honest: use a persistent session so TLS setup isn't counted in every call, warm the connection up before timing, and report percentiles rather than a single "typical" figure — latency in milliseconds is a distribution, and the p95 is what your worst-timed order will feel:

import time, statistics, requests

s = requests.Session()
URL = "https://api.binance.com/api/v3/time"
s.get(URL)                                      # warm-up: TLS + connection reuse

samples = []
for _ in range(200):
    t0 = time.perf_counter()
    s.get(URL)
    samples.append((time.perf_counter() - t0) * 1000)

samples.sort()
p = lambda q: samples[int(q * len(samples)) - 1]
print(f"p50={statistics.median(samples):.0f} ms  p95={p(0.95):.0f} ms  p99={p(0.99):.0f} ms")

What to look at in the output: the p50 is your geography, and the gap between p50 and p99 is your route quality — a tight spread means a clean path, a wide one means jitter that will bite exactly when markets move. One caveat for trading decisions: public endpoints answer through the CDN layer, so before committing to a server location, re-run the check with an authenticated call from your real key — that's the path your orders will take.

We keep our own latency statistics current by running this exact benchmark from our network (200 keep-alive calls to /api/v3/time, July 2026): from our Japanese addresses, p50 came in at 22 ms with p95 at 28 ms; from German addresses, p50 was 268 ms; from US addresses, 164 ms. The spread between regions matched the physics almost exactly — which is the point: your egress location is your latency.

Measuring FIX and WebSocket connections

REST is the slowest honest way to talk to Binance, because every request may pay connection overhead and full HTTP framing. The two faster transports change what "latency" even means, so they're measured differently. The WebSocket API latency story is about amortization: the connection is established once, so individual requests skip TCP and TLS setup entirely and travel over an already-open pipe. Measure it as request-to-response time inside a warm connection — the same percentile discipline applies — and expect it to sit visibly below your REST numbers from the same machine, with a tighter spread. For market data specifically, streams invert the question: you're no longer timing your requests but the age of the data when it reaches you.

FIX API latency matters for the sharpest end of the spectrum. Binance offers FIX on the spot market for order entry and market data — sessions authenticate with Ed25519 keys — and the protocol's fixed-format messages shave parsing and framing overhead that HTTP carries by design. The honest hierarchy from one location: REST slowest, WebSocket API meaningfully quicker per request, FIX quickest and steadiest. And the equally honest caveat: all three ride the same fiber. Switching protocols from Europe rearranges a few milliseconds on top of a 270 ms geography bill; moving the machine rearranges the bill itself.

How latency turns into slippage

Latency costs money through one mechanism: the market keeps moving while your order is in flight. Decide at price X, and by the time the engine sees your order — half your round trip later — the book has had 135 ms (from Europe) to change. In quiet markets that's usually nothing. During a volatile minute, when prices move tenths of a percent per second, a 270 ms flight time reliably converts into fills worse than the price you clicked — that difference is slippage, and it scales with your distance from Tokyo.

You can measure your own instead of trusting anyone's chart: run slippage on a test order. Record the best price you see at decision time, send a small marketable limit order, and compare against the fill price in the response — the transactTime field even tells you when the engine acted. Repeat it a few dozen times across market conditions and you have your personal latency tax in basis points, measured on your money, from your location.

That number is what decides whether low-latency API access is worth pursuing for you. If you trade actively — market making, chasing liquidations, arbitrage — the answer usually is: an egress point near ap-northeast-1 can substantially reduce that cost. If you collect data rather than race the book, the answer usually isn't: as we showed in our guide to Binance API rate limits, throughput is solved by parallelism across addresses, not by proximity. The geography split maps directly onto how our proxies for Binance get used: Japanese addresses for the order path, where every millisecond of round trip is priced in slippage, and packages across other regions for the data path, where budgets and parallelism matter more than distance — dedicated IPv4 either way, static for the plan term, with IP whitelisting included.