# What makes a tennis API the best > besttennisapi.com is operated by JSB Holdings LLC, which also operates Live Tennis API. This site is not independent. There is no single best tennis API — there is the one that survives your test. This page sets out eight things worth measuring, a test you can run for each, and Live Tennis API's measured numbers with the date and sample behind them. ## The eight criteria ### 01. Latency — How quickly does a scoring event reach your code? The delay between a point being recorded upstream and your process being able to act on it. It splits into the provider's processing time and your network transport — and a provider that does not let you separate the two is asking you to take its word. *How to test it:* Open the push feed and compare the two timestamps every frame carries: `published_at - timestamp` is the provider's processing time, and your own receive clock minus `published_at` is transport. If a feed carries only one timestamp, this test cannot be run against it. **Not yet measured.** No figure is published for this criterion. ### 02. Completeness — What share of matches actually carry every point? The proportion of completed matches whose point sequence has no gaps. Not the number of matches with *some* point data — the share where the sequence is whole. *How to test it:* Pull a month of completed matches, request each one's point sequence, and count the matches whose per-match completeness verdict says the sequence is whole. Divide by the completed matches in the same window — a ratio, not a total. **Measured: 75.0%** (as of August 19, 2026, over completed matches, January 2023 to date) - Caveat: This is the AS-SERVED share: the completed matches whose default tape read is measured point-complete. A different, lower figure counts only rows we observed live. The tape is not complete and is never described as complete. - Method: https://besttennisapi.com/methodology#completeness ### 03. Tour coverage — Which tours are in scope, and are they equally served? The tours a feed carries — ATP, WTA, Challenger, ITF, singles and doubles — and whether the depth is the same across all of them or concentrated at the top. *How to test it:* Ask for the live slate at several times of day, group it by tour, and compare against the published calendar for the same window. A feed that only ever returns tour-level matches is telling you its real scope. **Not yet measured.** No figure is published for this criterion. ### 04. Point-by-point — Is there a real per-point record, and does it say where it came from? A per-point sequence for a match, with each point's state, and an honest marker distinguishing points observed as they happened from points reconstructed afterwards. *How to test it:* Take a completed match, request its point sequence, and look for a provenance marker on each row. Points we watched live carry a real timestamp; reconstructed rows carry none. If every row looks identical, ask which ones were observed. **Measured: 25,747** (as of August 27, 2026, matches watched live from 0-0, every point carrying a real timestamp) - Caveat: A floor, not a coverage promise. Rows we watched live are distinguished from rows reconstructed afterwards, which carry no timestamp. Our own capture began 12 October 2025 at low volume; rows reach the product from March 2026. - Method: https://besttennisapi.com/methodology#observed ### 05. Streaming — Can you subscribe instead of poll, and how far does it fan out? A push transport that delivers score changes as they happen, addressable per match or across the whole slate, that holds up as the number of subscribers grows. *How to test it:* Subscribe to the whole slate, then open more connections and watch for dropped frames or refused connections. Check whether the transport is a real fan-out layer or a connection pinned to a worker thread. **Measured: 2,000** (as of August 18, 2026, concurrent subscribers, zero failures, staged at 500 / 1,000 / 2,000) - Caveat: Measured against the push sidecar directly, not through the public edge. It shows the sidecar held 2,000; it does not measure the full delivery path. - Method: https://besttennisapi.com/methodology#streaming ### 06. Free tier — Can you evaluate it properly before paying, without a card? A permanently free key with published limits that lets you run your real workload against real fixtures — not a countdown trial that expires mid-evaluation. *How to test it:* Sign up without a card, then run the calls your product would actually make and read the rate-limit headers. Check whether the limits are published as numbers or described as 'generous'. **Not yet measured.** No figure is published for this criterion. ### 07. Historical depth — How far back does it go, and what survives at that depth? The span of the historical record, and — separately — which fields survive at each depth. Results, serve statistics and point sequences do not reach equally far back. *How to test it:* Ask for a match from each decade and diff the fields you get back. Find the year each field you depend on actually starts, rather than trusting a single span. **Measured: 97,901** (as of September 1, 2026, 2013 to 2022 only) - Caveat: Coverage of play in those years is 19.3% overall and 44.9% of tour-level — both numbers or neither. ITF and futures are effectively absent. Matches from 1968 to 2012 hold a result and no point sequence. - Method: https://besttennisapi.com/methodology#historical ### 08. Spec and SDKs — Is the contract machine-readable, and is it kept honest? A published OpenAPI document that matches the live service, maintained client libraries, and reference documentation a machine can read without executing JavaScript. *How to test it:* Fetch the OpenAPI document, generate a client from it, and call three endpoints. Then fetch the reference page with JavaScript disabled and see whether any of it is there. **Not yet measured.** No figure is published for this criterion. ## Questions ### What is the best tennis API? There is no single answer, and any site that gives you one without telling you what it measured is guessing on your behalf. The useful question is which API survives the test your project actually needs it to pass. This site sets out eight criteria, gives you a test for each, and publishes what Live Tennis API scores — dated, with the sample size. ### Who publishes this site? JSB Holdings LLC, which also operates Live Tennis API. This site is not independent and does not present itself as a neutral review. What it offers instead is a method you can run yourself and raw data you can check. ### Why does this site not compare named competitors? Because a comparison is only worth reading if the person publishing it has measured both sides under identical conditions and has no stake in the result — and we have a stake. So we publish the measuring stick instead: the criteria, the method, and an open-source harness that runs the same tests against any provider, including ones we have never seen. ### How do I check a latency claim myself? Ask the provider for two timestamps on every push frame: when the event occurred and when the frame was published. The gap between them is the provider's processing time, and your own receive clock minus the publication stamp is transport. Live Tennis API carries both. A feed with one timestamp cannot be checked from outside, whatever it claims. ### Does a free tier exist, and does it need a card? Live Tennis API's free tier needs no card and is not a countdown trial — it is a permanent key with published limits, which is what you need to evaluate data quality rather than integration speed.