Methodology

How every number on this site is produced

Published before the figures, so you can judge the method rather than the marketing. If any of this looks wrong to you, the harness is open and you can run a better version of it.

The three rules

A figure carries its date and its sample, or it does not publish. This is enforced in code, not by policy: the claim type raises on construction if it has no as-of date or no method, and a latency summary returns nothing below thirty observations. A page with a missing measurement says “not yet measured”; there is no template path that prints a placeholder.

The vantage is declared, and it is never our own origin. Response time is mostly a statement about distance. Measured from the machine that serves the API, the network leg is a loopback no customer will ever traverse and every figure collapses toward zero while still looking like a real measurement. The prober therefore refuses to start if it finds an API origin process listening on loopback.

The caveats render next to the number. Not in a tooltip, not in a footnote, not on a different page.

Processing latency

Every push frame carries two clocks: the event timestamp and published_at, the moment the frame left us. The difference is time spent inside our pipeline. We publish its median over the run.

What this is not. It is not the delay between a point being played and the data reaching you. Nothing in this pipeline observes the court, so that number does not exist here and no figure on this site should be read as it. Your own transport time is the second half, and you can measure it yourself: your receive clock minus published_at. Frames whose two stamps disagree in the wrong direction are dropped rather than published as a flatteringly small number.

Response time

Sequential GETs of each free-tier endpoint, spaced so the probe does not distort what it measures or consume the published rate limit it is describing. Timings for non-2xx responses are discarded — a fast error is not a fast read — but they still count against availability.

Observed availability

The share of probes that returned a success, over a run of at least five hundred. Called observed availability and never uptime, and never written as a nines figure.

This is not an SLA. It is what one prober saw from one network location over a bounded window. Live Tennis API publishes no uptime commitment, and a number on this page must not be read as one.

Point completeness

The share of completed matches whose default point sequence is measured whole — a ratio, never a total, because a count of matches with some point data hides exactly the gaps you need to know about.

Two definitions exist, and they differ. The figure we publish is the as-served share: matches whose default read is point-complete. A stricter definition counting only rows observed live gives a materially lower number. Whenever a share appears on this site it states which one it is. The tape is not complete and is never described as complete.

Observed versus reconstructed

Points we watched live carry a real timestamp. Points rebuilt after the fact do not. These are different products for anything time-sensitive, and we never report them as one number. Our own capture began on 12 October 2025 at low volume; rows reach the product from March 2026.

Historical depth

Coverage figures for the reconstructed 2013–2022 corpus travel as a pair — overall coverage and tour-level coverage, both or neither — because either alone misleads in a different direction. Matches before 2013 hold a result and no point sequence.

Streaming fan-out

Staged concurrent-client load against the push sidecar.

Bounded claim. The test ran against the sidecar directly, not through the public edge. It shows what the sidecar held; it does not measure the full delivery path a customer actually uses.

Ratings

Rating counts come from the published corpus with its build date. Singles only; no junior ladder exists. Ratings publish on a lag and every response carries its own as-of date, so a backtest can pin the rating that was knowable at the time rather than the one we know now.

Conflict of interest

besttennisapi.com is operated by JSB Holdings LLC, which also operates Live Tennis API. This site is not independent. These are self-measurements by the operator of the service being measured. We think the right response to that is not to claim neutrality we do not have, but to publish the method, publish the raw data, and ship the tool — so that the least trusting reader can reach their own number without asking us for anything.