Live Tennis API changelog

Live Tennis API 1.13.78

2026-10-29T00:00:00Z

Changed

Shot-level winners and errors: where they are and when they are withheld. The family is present where the statistics source counts it: the 2026 Grand Slam main draws (Wimbledon and the US Open near complete, the Australian Open and Roland Garros filling as the completed-match statistics fetch walks back) and the odd regular-tour match. The earlier note that it had not been available since 2026-07-12 described live payloads of the regular tour and is replaced. A family the source filled with zeros is now withheld: a side that won 20 points or more with every by-shot winner and error at 0 is not measured, and the whole family is omitted, totals included. 33 of 33 Roland Garros 2026 qualifying payloads carried such zeros.

Live Tennis API 1.13.77

2026-10-29T00:00:00Z

Fixed

/fixtures and /matches tell one story. A fixture bound to a match (match_id set) is served with the match's status, in the fixture vocabulary, and the match's start_time, read at request time. The match row moves within minutes of a schedule change; the fixture row followed the 6-hourly refresher, so the two endpoints could disagree on the same match for hours. A customer found a Vienna match live at 09:00Z on one and upcoming at 12:30Z on the other. A vendor-stated cancelled or postponed on the fixture is kept. A null is_qualifying on the fixture takes the match's value when the match states one.
A bare digit in the schedule's status field is no longer a match in play. The day-ahead listing carries 1 on matches that have not started. It was read as a set in play, so 298 fixtures for 29 October were published as live. The digit is live only when the schedule's own in-play flag says so. The stored rows were restated the same day.

Live Tennis API 1.13.76

2026-10-28T00:00:00Z

Added

X-LTAPI-Signature-V1 on every webhook delivery. The value is t=<unix seconds>,v1=<hex>, and the hex is HMAC-SHA256 of <t>.<raw request body> with your webhook secret. The timestamp is inside the signed string, so a captured delivery re-sent later under a new time no longer verifies. Each body also carries a top-level delivery_id, unique per delivery, to dedupe on. The POST /webhooks description lists the receiver checks: a 5-minute timestamp window, a constant-time compare and a dedupe on delivery_id. It also lists score_withdrawn among the X-LTAPI-Event values, which it had left out.

Fixed

The webhook events enum matches what registration accepts. POST /webhooks listed stoppages, which registration refuses with a 400, and the Webhook schema listed only score and break_point. Both now read score, break_point, point, status.

Deprecated

X-LTAPI-Signature, the body-only webhook signature. It does not cover the timestamp. We keep sending it unchanged until 2027-02-01, and deliveries sent from 00:00 UTC on that date do not carry it. Both headers use the same secret, so moving to the new header needs no re-registration.

Live Tennis API 1.13.75

2026-10-28T00:00:00Z

Changed

Fields are described by what they hold. Rounds, stoppages, per-point tags, statistics and surfaces now say what each value means and when it is null. Earlier entries in this changelog were reworded the same way. The 2013 to 2022 archive tape is described as reconstructed point sequences with no capture timestamps. Its point_source_detail value is unchanged. The charting endpoints describe the charted corpus by its coverage. Nothing on the wire changed.

Live Tennis API 1.13.74

2026-10-26T00:00:00Z

Changed

The point-by-point page describes the tape by what it holds. The tape is the ordered score states we hold for a completed match, with coverage declared per match. The model's win probability sits only on rows that were observed live.

Live Tennis API 1.13.73

2026-10-26T00:00:00Z

Changed

Source links point at GitHub again. The github.com/livetennisapi organisation is public again, so every page, the README and llms.txt link each package's repository on GitHub beside its registry page. The Organization's sameAs names the GitHub org instead of the GitLab mirror.

Live Tennis API 1.13.72

2026-10-26T00:00:00Z

Added

duplicates_collapsed on GET /matches/{matchId}/points. How many rows of the page repeated a point the match had already published and were left out. The writer no longer stores such repeats; the count covers rows written before that. last_seq still advances past them.

Live Tennis API 1.13.71

2026-10-26T00:00:00Z

Fixed

Every docs page head carries the X (Twitter) card tag. The 2026-10-25 Ahrefs crawl listed twelve docs pages under "X card missing". The heads already carried the Open Graph tags, so the card tag names the card type and the rest falls back to Open Graph.

Live Tennis API 1.13.70

2026-10-23T00:00:00Z

Fixed

index.html's JSON-LD description is its meta description. The hub page's TechArticle carried a different sentence from its meta tag. The meta text is the one that fits the result-page budget, so the JSON-LD now repeats it. The generator's JSON-LD check covers index.html as well as the generated pages.

Live Tennis API 1.13.69

2026-10-23T00:00:00Z

Fixed

JSON-LD carries raw text, not HTML entities. The players page's TechArticle description read player's inside its JSON-LD while the meta tag decoded to player's: the topic, reference and changelog templates formatted the block with the HTML escaper, and a script element's text is never decoded. Every JSON-LD block is now built as a dict and serialized once with json.dumps, </ escaped as <\/. The reference and changelog descriptions in JSON-LD are the same text as their meta descriptions. The generator refuses a page whose JSON-LD does not parse, contains an entity, or whose TechArticle description differs from the decoded meta description.

Live Tennis API 1.13.68

2026-10-23T00:00:00Z

Changed

The docs' Organization node matches the apex page's. Every docs page publishes the same Organization as livetennisapi.com: alternateName and the ten sameAs profiles (RapidAPI, Apify, API.market, Postman, GitLab, PyPI, the two npm packages, the docs site and X). Ahrefs flagged the docs node as incomplete while it carried only the name, url and logo.
Titles fit 60 characters and descriptions 110 to 155. Three topic pages carry a shorter head title than their h1, the authentication page's description says what GET /usage is for, and a description the budget cuts no longer ends on a connective. The generator refuses a page outside these budgets, index.html included.

Live Tennis API 1.13.67

2026-10-22T00:00:00Z

Fixed

/players/{playerId}/stats keeps a UTC instant as given. from and to are compared as instants, and window echoes what was applied. An instant inside a repeated daylight-saving hour was read through a local wall clock. to=2025-10-25T22:30:00Z came back as 23:30Z with from an hour late, from=22:30Z&to=23:15Z was refused and the reversed window was accepted. The same ordering applies to from and to on GET /matches and GET /history/matches.
An omitted to is the request instant. It used to be rounded down to the minute, so a from a few seconds earlier answered 400 bad_date. Polls without to inside one minute still share a cached response, and its window.to is the first poll's instant.
freshness.measured.complete and serve_return.matches_with_stats are one judgement. A deciding match tiebreak written as its points in the stamp and as one game in the served final, or the other way round, is the same finished set. The statistics endpoint compared the totals first and answered null one way and false the other, while the player aggregate counted the match complete. The field text now says what the judgement is.
PlayerRecentMatch.score.games are the games the match object publishes. The recent scores go through the same projection as GET /matches/{matchId}, so a deciding match tiebreak the row keeps in points is rendered into the deciding-set games slot. Before this, the stored lists were read raw and a match that ended in the breaker showed one set fewer.

Live Tennis API 1.13.66

2026-10-22T00:00:00Z

Fixed

Player.tour describes a doubles team the way the API decides it. A team filed under a circuit of its own carries that circuit. Only a team filed under a level word or nothing falls back to the circuit both its members share, and it is null when they disagree or either is unknown. The 1.13.63 text put the fallback first. The field for singles or doubles is the match's draw, not its gender.
Parameter tables show numeric bounds. Every parameter with a minimum or maximum now says so next to its default. /players/{playerId}/stats?last= reads as 1 to 50, where it used to show only the default of 20.
The AI SDK guide says how check_api_status detects the plan. livetennisapi-ai 1.3.0 reads /usage and reports the key's own tier, so a FREE key with History access reports as FREE. The BASIC estimate applies only to the fallback probe, used when /usage cannot be read.

Live Tennis API 1.13.65

2026-10-22T00:00:00Z

Changed

The AI SDK guide now pins livetennisapi-ai 1.3.0, which adds player_stats (PRO, with serve_return on ULTRA). The guide and llms.txt now say 25 tools, the same set as livetennisapi-mcp 1.6.1.

Live Tennis API 1.13.64

2026-10-22T00:00:00Z

Changed

The AI SDK guide now pins livetennisapi-ai 1.2.1. That release fixes check_api_status for FREE keys, so the known-issue note and its workaround are gone.

Live Tennis API 1.13.63

2026-10-22T00:00:00Z

Fixed

serve_return.matches_incomplete is documented. The API already returns it. It counts matches whose measured statistics stop short of the final. Those matches are left out of every sum.
serve_return.matches_with_stats says what it counts. It counts only matches whose measured statistics reach the final, and only those are summed.
GET /players documents its 400 response. A restated_since that is not an ISO-8601 instant answers bad_restated_since with the Error body.
Player.tour lists the values the API sends. They are atp, wta and null. The old text described capitalised and level values that have not been served since 2026-09-24.
Field tables show nested fields. Inline objects are spelled out as dotted paths, such as sets.tiebreaks and serve.first_serve_in. A field typed by a named schema links to that schema's table.
Changelog list items keep their continuation lines. An unindented line under a bullet rendered as a paragraph inside the list. That is invalid HTML.
The AI SDK guide states a known issue with FREE keys. In livetennisapi-ai 1.1.0, check_api_status reports a FREE key as unreachable. The guide names the workaround until 1.2.1 is on npm.

Live Tennis API 1.13.62

2026-10-22T00:00:00Z

Fixed

PlayerRecentMatch.opponent is nullable. The endpoint returns null when the match row holds no opponent id. The schema said it was always an object.
PlayerRecentMatch.score.games values are nullable integers. The per-set lists are passed through from the stored row as GET /matches/{matchId} serves them, and nothing on that path coerces the values.
records.last_12_months now says what window it covers. It is the 365 days ending at to, whatever from says. With the default window it equals overall.
The /players/{playerId}/stats 400 response references the Error schema. It names the five codes and says that bad_surface and bad_level list the accepted values in allowed.
The Player schema gains seven fields the API already returns. They are ranking_status, ranking_checked_at, itf_ranking, profile_restated_at, profile_version, archive_player_id and itf_id (ULTRA only). GET /players gains the restated_since parameter that profile_restated_at points to. Nothing changed on the wire.
llms.txt and the plans table name the new endpoint. /players/{playerId}/stats is listed under PRO and its serve_return block under ULTRA.
The players topic page no longer says /rankings per-player as-of records are PRO. The rank-ordered listing is PRO, and the as-of records are ULTRA.

Live Tennis API 1.13.61

2026-10-22T00:00:00Z

Added

GET /players/{playerId}/stats (PRO; serve_return ULTRA). One player's record over our own completed singles matches, 2023 onward. The default window is the 365 days ending now, and ?from=, ?to=, ?surface=, ?level= and ?last= narrow it. PRO gets records: W/L overall, over the last 12 months, and by surface, venue, level and season. It also carries the set-based record (tiebreaks, deciding sets, after winning or losing the first set, comebacks, sets won and lost), withdrawals given and received, and the last N matches with the score turned round to the player. Every count carries its sample size, and a percentage on an empty sample is null, not 0. Winners and scores are read the same way the match object publishes them, so this endpoint cannot disagree with GET /matches/{matchId}. ULTRA adds serve_return, the per-match statistics of /matches/{matchId}/statistics summed over the window. Each ratio is published as numerator, denominator and pct, with the number of matches behind it. Below ULTRA the key is absent. A doubles-team id answers 400 doubles_not_supported, and a merged or retired id answers 410 as /players/{playerId} does. For 1968–2022, /history/archive/career remains the endpoint.
height_cm and doubles_ranking on GET /players/{playerId}. Both are on the single-player read only, on paid tiers, and null on a FREE key. height_cm comes from the results archive's record of the same person and is never inferred. doubles_ranking is {rank, points, observed_on}, the current position on the official ATP/WTA doubles table. It is null when the player is off the table or was last seen there more than 21 days ago. It is never copied into ranking, which stays the singles position. Nothing existing changed type or meaning.

Changed

The licence is named by its SPDX identifier. info.license now carries identifier: MIT in place of a URL. The old URL pointed at a GitHub page that no longer loads. No endpoint, field or type changed.

Live Tennis API 1.13.60

2026-10-03T00:00:00Z

Added

The hosted MCP endpoint, which this reference had never mentioned. A remote Streamable HTTP server has run at https://mcp.livetennisapi.com/mcp for weeks. The only MCP line here named the self-run package, npx livetennisapi-mcp. A reader who wanted an LLM agent over this API was therefore told to install and host one. The string mcp.livetennisapi.com appeared zero times in the reference, zero times in llms.txt and zero times in the README. An engineer evaluating the API found the endpoint by going looking for it, which is what prompted this. A new MCP server section now sets the hosted and self-run routes side by side. The client-libraries table, llms.txt and the README name the endpoint too. Everything in the section was read off the live server on 2026-10-03, not taken from a release note. initialize reports serverInfo version 1.5.0. tools/list returns 24 tools, set-identical to the 24 the section lists by name. Both documented auth headers were called and both work: Authorization: Bearer twjp_... and X-API-Key: twjp_.... The rate headers read limit=300 on a key and limit=60 without one. The section states both, and states that the caller's own plan limit still applies underneath. That second sentence is load-bearing. The hosted cap sits above a free key's 30 a minute, so publishing it alone would read as a quota raise. With no key at all only check_api_status answers, and it returns the free-key URL. GET /mcp answers 405 "use POST", so the section says POST only. GET /health reports the running version. Every plan reaches MCP, free keys included, and each tool reaches exactly what that plan reaches. No price is quoted anywhere, because the endpoint takes the key a customer already has. No field, parameter or type changed, and no endpoint of the REST API changed.

Live Tennis API 1.13.59

2026-10-02T00:00:00Z

Added

?is_qualifying= on /matches, /history/matches and /fixtures, and ?gender= documented on the same three. The is_qualifying field has been published on every match and fixture since 2026-08-12 and this reference already called it "the only field that separates a qualifying draw from the main draw" and told callers to "filter accordingly" — while the parameter they would reach for did not exist and was accepted and ignored. Measured on prod before the change: /matches?status=completed&limit=50 returned the same fifty ids under is_qualifying=true, is_qualifying=false and no filter at all, every one of the fifty rows carrying is_qualifying: false, while the ?draw= control changed the page. The filter is applied in SQL before the page limit on status=live, upcoming, completed and cancelled and on the archive listing, so a deep crawl can page a single draw rather than filtering a full corpus client-side. It is three-valued like the field: a row whose flag is null matches neither true nor false and is returned only when the filter is omitted, because returning it under false would assert "main draw" on the strength of nothing. Coverage, measured 2026-10-02 over completed matches: the flag is stated on 98.9% of the last thirty days and 98.3% of 2026 outside the UTR circuit, which is where almost all unstated rows are (1,695 of the 1,831 in the last thirty days). Anything other than true/false is a 400 bad_is_qualifying. Asked for by a customer splitting qualifying from main draw for a match-prediction model. ?gender=men|women has worked on the match and archive listings since 2026-09-09 and was never documented here; it is now, with the same null contract — a mixed-doubles or team-tie row matches neither value. No field or type changed.

Fixed

?gender= was accepted and ignored on /matches?status=live and ?status=upcoming. Those two statuses are served from a short-lived slate cache keyed only on the status, and the gate that decides whether a request may use it never learned about gender, so a filtered request was answered with the whole slate under a 200. Measured on prod before the fix: status=live returned the same twenty-five rows for gender=men, gender=women and no filter — six of them women's matches and seven with no gender stated — and status=upcoming the same sixty rows of a hundred and forty-three under every value. status=completed and status=cancelled are not cached and answered correctly throughout (sixty of sixty, pure), so the filter itself was never wrong: the request did not reach it. The live listing is polled continuously, so the cache was effectively always warm and the filter was dropped on every call rather than occasionally. Present from 2026-09-09 to 2026-10-02. Callers who filtered the live or upcoming slate by gender and trusted the result were served the unfiltered slate and should re-read anything derived from it; every row carried a correct gender field throughout, so a client that filtered on the field rather than the parameter was unaffected.

Live Tennis API 1.13.58

2026-10-01T00:00:00Z

Changed

The archived tape's accept clock now begins 2026-08-11, six weeks earlier than 1.13.57 published, because the missing values were recovered rather than written off. 1.13.57 measured the boundary honestly at 2026-09-23, the day history_archived_scores.content_changed_at landed as a catalogue-only column with no backfill. What that measurement did not say is that the values were still reachable: for every archive row copied before the column existed, the live row it was copied from may still be inside the 90-day retention, and that row holds the value the archiver would itself have written. A backfill carried them across on 2026-10-01 in six bounded tranches, 1,413,471 accept clocks and 1,393,458 accept counters, inside 1,538,176 rows over 14,491 matches, and left fillable=0. Nothing is derived, rounded or taken from a neighbouring row, and a row whose live row had already been trimmed stays null for good. Measured after the run: the archive carries the clock on 100.0% of every day from 2026-08-11 to 2026-10-01, 92.5% of 2026-08-10 (the live column's own first instant is 2026-08-10T08:07:42Z) and 0.0% of every day before it, which is 1,721,102 of 4,663,181 archived observed rows against 307,631 before. HistoryTapeRow.sequence, the accept counter, has its own later floor because live_scores.match_seq landed after the clock: nothing to 2026-08-13, 68.2% of 08-14, 99.3% of 08-15, then 95.9% or more of every day from 2026-08-16 and 100% from 2026-09-01. Two boundaries, not one. received_at could not move at all and the reference now says so: its live column landed 2026-09-24, a day AFTER the archive column, so every live row carrying an arrival clock was archived with it and the recoverable count is zero. Wire-verified both sides: match 2168 (26 April 2026), before the boundary, still answers 131 observed rows with timestamp on all 131 and accepted_at on none; match 189679's archived copy carried the clock on 0 of its 171 observed rows before the run and on 171 of 171 after it. The practical consequence for a timing study is that the clock no longer disappears when a match ages out of live retention. No field, endpoint or type changed.

Live Tennis API 1.13.57

2026-10-01T00:00:00Z

Fixed

HistoryTapeRow.accepted_at was documented as covering the whole observed corpus, and on an archived tape it begins 2026-09-23. The field is the one this reference tells a timing study to use, and its description read "It rides the whole observed corpus, so a study that spans 2026-09-24 must use this one and not received_at", while received_at said "THIS CLOCK HAS A START DATE AND THE OTHER TWO DO NOT". Both sentences were wrong about accepted_at. Measured over the whole archived observed corpus: 307,512 of 4,659,024 rows carry it, which is 0.0% of every month to August 2026 (286 rows in all of August), 27.3% of September and 100% of October. Wire-verified on match 2168 (26 April 2026), answered with meta.from_archive: true: 131 observed rows, timestamp on all 131 and accepted_at on none. The measurement quoted in 1.13.5x — match 189679, accepted_at on all 171 observed rows — is correct and does not generalise, because that match is still inside live retention and is answered from its live rows (from_archive: false); its own archived copy carries the clock on 0 of 367 rows. So coverage depends on which copy answers the read, meta.from_archive is how you tell, and a null here is a boundary of the record rather than a missing value. timestamp is the only one of the three clocks with no start date. Found while answering a customer who asked for "a timestamp precise enough to line up with exchange quotes" — the exact question the wrong sentence was there to answer. No field, endpoint or type changed.

Live Tennis API 1.13.56

2026-10-01T00:00:00Z

Fixed

An exact player name that sat inside a longer name could not be asked about on any of the three name endpoints. Every name lookup is a substring match, so there was no way to say "exactly this one", and a person whose name is a prefix of somebody else's was unreachable: GET /h2h?p1=Carlos%20Alcaraz answered 400 ambiguous_name listing Carlos Alcaraz and Carlos Alcaraz Gonzalez, with no string that could pick between them. Measured on the live roster and corpus: 14 of the 1,177 ranked players on /h2h, 21 of 1,500 distinct archive names on /history/archive/career and 4 of 1,739 charted names on /charting/players, the men's world #2 and #3 among them. Passing a name exactly now selects that person on all three. A name given in part is still a fragment and still refuses with the candidate list, so Sinner continues to list Jannik and Martin rather than guessing, and a single name charted under both genders on /charting/players still needs gender. The refusal also reports the candidates it would have shown before the exact match was applied, so a hint never gets shorter than it was. Verified on the wire: Alcaraz against Sinner returns 18 meetings 11-7 with the surface split and the ULTRA aggregates. No field, endpoint, parameter or error code changed.

Live Tennis API 1.13.55

2026-09-29T00:00:00Z

Fixed

ITF World Tennis Tour doubles began stating outcome, and the reference still said no doubles draw carries either field. The 1.13.42 note measured 454 completed doubles matches and found no tagged row. That was true when it was written. The first doubles row carried a tag on 2026-09-23, and by 2026-09-29 GET /matches/{id}/points published outcome on 104 of 596 completed ITF doubles matches, 17%, against 0 of 371 for the ATP, WTA and Challenger doubles draws in the same window. The vocabulary is ace and double fault, as on the ITF singles draws. serve is still unstated on every doubles draw, measured 0, and that sentence is unchanged. The cause sat before the tagger: a dedup change let a doubles fixture be adopted and oriented by its member sets instead of being refused, so the ITF per-point join reached rows it had never been able to match. 17% falls between "almost none" and "a clear majority", so the description states it as a measured fraction and sends the reader to enrichment per match instead of to the draw. WTA main-tour qualifying has carried that treatment since 1.13.42. Found by the every-sweep tag-coverage check. No field, endpoint or behaviour changed.

Live Tennis API 1.13.54

2026-09-28T00:00:00Z

Added

The two broadcast surfaces, live since 2026-09-24 and documented nowhere a customer could read. GET /broadcast/match/{matchId} and GET /broadcast/live have served every ULTRA key for four days and appeared in no published reference: the write-up went into the tennis repository, which nothing serves. Both are now specified, with the 54-field BroadcastObject schema in the same order the API returns it, verified field by field against a live response rather than transcribed from the source. The object exists because a graphics template binds each field to a fixed path, so three properties are contractual rather than incidental and are documented as such: it is FLAT, every key is PRESENT on every read (null, never missing — a missing key breaks a binding), and the score is already in DISPLAY form (p1_points reads "40" or "AD", set_line is one string, each set has its own column). It is a projection of what the API already publishes plus the break-, set- and match-point flags the scoring pipeline derives; nothing in it is a new fact and nothing is guessed.
The 1 Hz polling contract, which is the part a live scoreboard gets wrong. Every response carries a strong ETag and Cache-Control: no-cache, max-age=1, so If-None-Match turns an unchanged state into a 304 with no body; ULTRA's 600-a-minute burst window means ten single-match pollers at 1 Hz fit on one key, and /broadcast/live stays one request however many matches are live. A new state is detected on sequence, never on served_at, which changes on every read — stated on both routes because polling on served_at is the mistake that looks like it works.

Live Tennis API 1.13.53

2026-09-26T00:00:00Z

Added

The tape now publishes the accept counter the withdrawal ledger points at. GET /matches/{matchId}/withdrawals tells you a sequence was withdrawn and to resume from replaced_by_sequence, and until today no served history-tape row carried that number, so the pointer named a row nothing identified. HistoryTapeRow.sequence is the same per-match accept counter as Score.sequence on a live read. Because a withdrawn state never enters the record at all, a withdrawal now reads as a GAP in the tape's run of counters, which is what makes "resume from the predecessor" resolvable against the served history. Reported by an Ultra customer who verified three withdrawal records against the tape and wrote that "the history rows lack sequence IDs, so these responses alone cannot reconstruct exactly what a live client received". Null, never fabricated, on a row archived before 2026-09-26 (the archive did not keep the counter, so it died with the live row at retention) and on the pre-2023 archive tape, which has no such counter. Unlike accepted_at and received_at it is NOT null on a reconstructed row: a counter is a fact about our own accept order.

Fixed

Score.sequence said the tape does not carry it, and the stated reason was the gap. The description read "absent on history-tape rows, which are already served in order". Being served in order does not resolve a replaced_by_sequence, which is a pointer at a counter rather than a position in a list. Corrected, and it now points at HistoryTapeRow.sequence.

Live Tennis API 1.13.52

2026-09-25T00:00:00Z

Added

The tape's two accept clocks are published. HistoryTapeRow.accepted_at and HistoryTapeRow.received_at have ridden every observed row of GET /history/matches/{matchId} since 2026-09-24 and were documented nowhere, so a customer doing timing research on a tape had no published field to read. accepted_at is the instant our arbiter accepted the state, stamped once and never refreshed, which is the clock to difference against: timestamp starts equal to it and is then refreshed while the owning source keeps re-asserting the unchanged state, so on most raw rows timestamp is a later re-assertion instant (on match 189679, 164 of its 171 observed rows carry a timestamp more than a second after accepted_at). received_at is the instant the state reached our edge before arbitration, so accepted_at minus received_at is our own arbitration step. Neither figure is a claim about speed before our edge and neither is the court's clock. Both are null on every reconstructed row, which never had a clock.
The arrival clock's start date, which is the part that bites. received_at is stamped only as a state arrives, so it can never be filled in afterwards. The earliest one we hold is 2026-09-24T02:00:26Z; on every observed row accepted before that instant it is null while timestamp and accepted_at are populated. A study that spans the boundary has to read accepted_at, which rides the whole observed corpus. Measured on match 189679 (12 September) after a Basic customer reported it: 171 observed rows, accepted_at on all 171, received_at on none.
What server guarantees on a tiebreak row, and what it does not. Tiebreak rows are never settled on either sequence. The server genuinely changes during a breaker, so there is no constant to take a majority of, and the field is the source's own assertion carried through. Where a breaker's rows skip points the rotation cannot be reconstructed from what is served: you have the server of a state, not of a numbered point, and meta.points.transitions_legal against transitions_total tells you whether that happened. On the set roll-up row carrying tiebreak_final, server is the value of that committed set-end state and is NOT a preserved copy of the final breaker point's server. Reported by a Basic customer who could not reconcile 21 tiebreak transitions against the standard rotation and was right not to.

Fixed

Score.accepted_at said "absent on history-tape rows". It has been present on them since 2026-09-24, so the description had been wrong for a day, on the one field a timing study is told to use. Corrected, and the tape row now documents its own copy.

Live Tennis API 1.13.51

2026-09-25T00:00:00Z

Added

The score_withdrawn frame is documented on the push feed page, where a streaming consumer looks for it. 1.13.50 put the record and the frame's fields on the score read and in the schema list, and the frame is a STREAM artifact: it arrives on the same channel as the score frame it retracts. GET /ws-token now carries the frame itself, the reason it exists (the feed publishes every accepted state and runs no trust deference, while the score read runs the legality gate and can serve an older state), what each kind asks you to do, and the three reads that recover a judgement you were offline for. No spec surface changed.

Live Tennis API 1.13.50

2026-09-25T00:00:00Z

Added

A withdrawn score state is now recoverable, and GET /matches/{matchId}/withdrawals serves the record. The verdict object has told a stream consumer since 2026-09-23 that a state it holds was taken back, but it is recomputed on every read over the newest state, so it returned null again as soon as the next state was accepted. In a live match that is seconds. A consumer that disconnected and missed the score_withdrawn frame had no way back to it: the publisher's duplicate ledgers live inside the publishing process, and nothing else recorded the judgement. Every withdrawal is now written down when the judgement is made, before the frame goes out. Three reads use it. GET /matches/{matchId}/withdrawals (ULTRA, the tier that receives the frame) returns every refused sequence on a match, oldest first, each with kind, reason, withdrawn_at, published_at, the sequence served in its place, and the frame exactly as the feed sent it. GET /matches?withdrawn_since=<instant> lists the match ids with a withdrawal since then, with a count per match, so a consumer coming back after a gap knows which matches to ask about. And ?sequence=N on GET /matches/{matchId}/score makes verdict answer for the one sequence you hold, even after later states have landed. Records are kept 90 days from the withdrawal.
The score_withdrawn frame's own fields are published for the first time. type, match_id, kind, superseded_sequence, reason, safe_to_resume, ts and published_at. It carries NO replacement score and no new sequence, which is the question a customer had to ask us: the state to resume from is the one on the next score frame, or on a fresh GET /matches/{matchId}/score, and the sequence served in the refused state's place is on the withdrawal record rather than on the frame. ts is when the judgement was made, published_at when the frame was handed to the feed.

Changed

Only a discarded withdrawal is re-asserted by ?sequence=. A deferred state may since have been corroborated and a withheld read described that moment's scan, so neither answers from the record; a verdict the read produces itself always wins, because it describes the state actually being served. ?sequence= changes verdict and nothing else on the object. A non-integer is 400 bad_sequence rather than an accepted-and-ignored filter, because a silently dropped lookup would read as "not withdrawn". ?withdrawn_since= likewise takes only limit and offset beside it: any match filter, status or updated_since alongside it is 400 bad_withdrawn_since.

Live Tennis API 1.13.49

2026-09-24T00:00:00Z

Fixed

The tournament catalogue takes ?tier=, which it had been accepting and ignoring. GET /tournaments publishes each row's tier and tier_source, and the two match listings have filtered on the same vocabulary since 1.13.28. The catalogue did not: ?tier=atp_500, ?tier=laver_cup and an outright invalid value each returned the entire 10,302-row catalogue under a 200, byte-identical to no filter at all, because the level was attached to a page after it had already been selected. It now selects. The one difference from the match listings is the season, and it is stated on the parameter: a catalogue row has no season of its own, so ?tier= here reads the CURRENT season, the same season the row's own tier field reports, while on /matches and /history/matches it reads each match's own season. A tournament with no row for the current season matches no value. An invalid value is now a 400 bad_tier carrying the vocabulary, as it always was elsewhere.

Live Tennis API 1.13.48

2026-09-24T00:00:00Z

Fixed

tiebreak_final on the history tape row is documented for the first time, and the page-first rule the reference stated is no longer true. A PRO customer wired a bot to the closing score and reported that match 195134 served a tiebreaks array of {p1: 2, p2: 7} while no tape row carried tiebreak_final, and that it stayed that way on every later read. Two things were wrong here. The field had never appeared in this reference on HistoryTapeRow at all, though it is served on GET /history/matches/{matchId} and a customer had been pointed at it in writing; it is now described beside is_tiebreak. And the MatchPoints text said a page that *starts* on a roll-up row "has no previous row to read and uses the recorded finals alone", which was true when written and is not true now: since 2026-09-24 such a page reads the one row before it, so the value does not depend on where the page was cut. Both endpoints resolve the score the same way and agree with the response's own tiebreaks array.
The row that closes a tiebreak set carries the score whichever row the set counter moves on. The tape's set counter lags the games array by a row: the row that took 195134's first set to 6-7 still read sets [0, 0], and the counter reached [0, 1] on the row after it. The stamp only fired when the counter grew on that same row, so a set whose counter lagged was never stamped, and nothing revisits a tape. The games on the row now decide it, judged by the tournament's own set test so the Next Gen first-to-4 format is read by its own rule. Measured on the live endpoint before the change: of 9 live matches whose tiebreaks array stated a final, 2 carried it on no row, both first-set breakers.

Live Tennis API 1.13.47

2026-09-24T00:00:00Z

Changed

A set completion that does not end the match is assigned a sequence only once confirmed. Live since 2026-09-24 and stated here for the first time. A live scoring display can render the set-ending frame ON set point, before the point is decided, and step back when the point is not won; a customer measured exactly that twice. A rise in sets that does not end the match, arriving while the state we hold is set point for the side that would gain the set, is now held until the same source keeps presenting it for 10 s or more, a source at least as trusted presents it, or the same source shows play continuing inside the new set. The unconfirmed frame is never stored, so no sequence ever carries it and nothing is published as provisional — a sequence that carries a set completion is one that met the rule. Until then GET /matches/{matchId}/score, the push feed and the WebSocket all keep serving the set-point state; a frame nobody confirms within 120 s is discarded. A set completion that ends the match is exempt and follows the completion rules instead. Measured over the 30 days to 2026-09-24: a median 10 s added between the point and the published set-end, and on a feed that does not re-present states the set-end lands with the first point of the next set (90th percentile 133 s). It does not cover a set genuinely won and then corrected on court, which can still be published and rewound — read corroborated beside it, and verdict says so when a state is taken back.

Live Tennis API 1.13.46

2026-09-24T00:00:00Z

Added

corroborated and corroborated_age_seconds on the Score: has an independent source vouched for THIS EXACT state? Raised by a customer who acted on a completed set that was taken back seconds later. corroborated is true when a source other than the one that wrote the state has since presented us the same state, false when none has — including a brand-new state nobody has had a chance to agree with yet — and null on the archive fallback of a retention-trimmed completed match, where age_seconds and sources_count are null too. corroborated_age_seconds is the seconds since that vouch, null when there is none. This is the field to gate a set-end on. sources_count and changing_sources_count are window measures over the match and say nothing about the state in front of you, so a set completion that only one source has announced can sit beside a perfectly healthy count — and a set-end is the one state whose correction changes a result rather than a number. It is evidence, not proof: a vouched state can still be corrected, so compare corroborated_age_seconds with age_seconds and treat a vouch younger than the state it vouches for as the weaker signal it is. When a state is taken back the sequence goes down and verdict says so. Present wherever sources_count is; a yes/no, never a name.
changing_sources_count on the Score is documented. Live since 2026-09-24 and absent from this reference. How many distinct sources CHANGED the score in the last 300 seconds, counted on the content clock alone, so a source re-asserting an unchanged state is not counted — the difference from sources_count, which a feed stuck re-sending its last state holds at 1 for as long as the echo lasts while this reads 0. The window is wider on purpose: a point lands every 30-60 s and a changeover is about 90 s. A cross-confirmation is agreement, not a change, so this can read below sources_count and never above it.

Live Tennis API 1.13.45

2026-09-24T00:00:00Z

Added

GET /history/incidents and GET /history/incidents/{incidentId}/matches are documented for the first time. Both have been live and neither appeared anywhere in this reference, so the register a customer is meant to reconcile against could not be found from the documentation. /history/incidents returns the published data-quality incidents, oldest window first, each with its window_utc (start, end and the basis it was read from), rule_before, rule_after, defect, affected_surfaces, how_to_tell, corrections and matches. The register is part of a release and is not inferred at read time, so a record does not change between releases. /history/incidents/{incidentId}/matches streams one row per affected match as JSONL, or CSV with ?format=csv, with the columns incident_id, match_id, tournament, tour, round, draw_stage, scheduled_time, affected_field, served and expected. A match whose derivation would be a guess is left out and the incident's matches.note says which, so the export is exact rather than complete. Measured on the live API 2026-09-24: five incidents across the kinds pricing_rule, version_stamp, field_orientation and field_repair.
The verdict object on the Score is documented. Live since 2026-09-23 and absent from this reference. It is null on an ordinary read. When the legality gate refuses a state a stream has already published, it carries kind (withdrawn, deferred or withheld), superseded_sequence (the sequence a stream consumer is holding), reason and safe_to_resume, which is true exactly when kind is withdrawn. The push feed, the WebSocket and webhooks announce the same judgement as a score_withdrawn frame naming the same sequence, so a stream consumer learns a state was taken back without polling. GET /matches/{matchId}/score now names the field and points at the incident register.

No field, endpoint or behaviour changed by this release; both were already served.

Live Tennis API 1.13.44

2026-09-23T00:00:00Z

GET /matches/{matchId}/points: the row that closes a tiebreak set now carries tiebreak_final, and the reference did not say so. Raised by a Pro customer running trading bots, who reported that the tape stops one point short of every tiebreak and that a field filling once a day was no use to a decision taken while the match is live. A tiebreak's last point is carried, like every set-winning point, by the set roll-up row (tiebreak false, the set banked 7-6, score 0-0), and that row never stated the breaker's score at closure. It now carries tiebreak_final: [p1, p2] in our player order, e.g. [7, 5]. Exact when the previous row is the decided score or one point from it, so it is derived from the stream itself and is present as soon as the set closes; otherwise taken from the match's recorded tiebreak finals, the same finals GET /history/matches/{matchId} publishes as tiebreaks; null when neither can state it, never guessed. Absent on every other row, including the breaker rows. A page that *starts* on a roll-up row has no previous row to read and uses the recorded finals alone. Measured at the endpoint over the 30 hours to 2026-09-23 20:30Z: 60 completed matches held 67 tiebreak sets and 36 of them served a closing score, only 7 of those matches having a recorded final at the time. Documentation of an already-served field; no behaviour changed by this release.

Live Tennis API 1.13.43

2026-09-23T00:00:00Z

Fixed

The reference said a FREE key is refused the history endpoints outright. It is not, and has not been since 2026-08-07: a FREE key is served 20 history calls per calendar month. Three separate statements carried the wrong rule — the FREE tier summary ("No historical results"), the /matches description ("requires BASIC ... and returns 403 upgrade_required on a FREE key"), and the status parameter. Measured on the live API 2026-09-23 with a fresh FREE key: GET /history/matches answered 200 and kept answering until the monthly allowance was spent, after which it answered 403 upgrade_required carrying free_history_taste: "used" and the detail "your 20 free history calls this month are used". A reader planning against the old text would have concluded the endpoints were closed to them and either bought a tier they did not yet need or abandoned the evaluation; a reader who tried anyway got a 200 the reference said was impossible and could not tell an allowance from a private grant. /history/matches, /history/coverage, status=completed on /matches and the FREE tier summary now all state the allowance and the refusal that follows it.

No field, endpoint or behaviour changed; every correction is to a description.

Live Tennis API 1.13.42

2026-09-23T00:00:00Z

Fixed

Every per-point coverage count in this reference was measured in our own tables and published as though it described the API. It did not, and the gap is large. GET /matches/{id}/points serves a COMPLETED match's stored per-point stream only while that stream passes our quality bar. Where it does not, the endpoint serves a measured-complete RECONSTRUCTION instead, and a reconstruction carries no clock and no serve / outcome tags at all. So the share of matches whose tags a reader can fetch is lower, sometimes far lower, than the share of matches a source tagged. Re-measured 2026-09-23 on what the endpoint publishes, beside what the previous text claimed: Davis Cup World Group serve 2 of 22 (published as 22 of 22), World Group I 1 of 42 (published as 41 of 42); WTA qualifying serve 18 of 48 (published as 48 of 48); ATP Challenger qualifying serve 137 of 197 (195 of 197) and outcome 134 of 197 (191 of 197); WTA 125 qualifying serve 47 of 63 (61 of 63) and outcome 30 of 63 (24 of 63); ITF qualifying outcome 181 of 215 men's and 142 of 176 women's (189 of 209, 143 of 168); WTA main-tour qualifying outcome 5 of 48, against 47 of 88 in the same events' main draws (published as 3 of 48 against 82 of 88). Both descriptions now state which layer they count and name basis as the per-response answer.
enrichment per match was correct throughout, on every one of these matches, and basis has always named which sequence you were given. Only the prose was wrong.

No field, endpoint or behaviour changed; every correction is to a description.

Live Tennis API 1.13.41

2026-09-22T00:00:00Z

Fixed

The outcome description named the wrong tour as the qualifying gap, and it was wrong in both directions. It read "Qualifying draws follow their own tour, with one gap: ... Challenger (men) qualifying states no outcome at all." Measured 2026-09-22 over completed matches carrying a per-point stream since 2026-09-12, ATP Challenger qualifying states outcome on 191 of 197 matches, with the full five-value vocabulary (6,881 unforced errors, 4,275 winners, 4,267 forced errors, 1,026 aces, 774 double faults) — a reader who segregated a corpus on that sentence discarded the single richest qualifying population in the product. The gap is on the WTA main tour, which the old sentence implicitly cleared: WTA qualifying states outcome on 3 of 48, against 82 of 88 in the same events' main draws. ITF qualifying is unchanged in direction (189 of 209 men's, 143 of 168 women's) and WTA 125 qualifying is partial (24 of 63). enrichment per match was correct on every one of these matches throughout — only the prose was wrong, and the prose is what a corpus is planned from.
tour: challenger pools two populations with different outcome coverage, and the reference described only one of them. It read "Challenger: all five". That is true of ATP Challenger (tier: challenger_50 … challenger_175): 252 of 255 completed main-draw matches with a stream carry the full five. It is not true of the WTA 125 events, which are also served as tour: challenger (tier: wta_125) and state ace and double fault only — 137 of 141 main-draw matches carry outcome, none of them a winner, forced error or unforced error. Read tier, not tour, to tell the two apart. Both descriptions now say so.
The serve qualifying denominators are re-measured (WTA qualifying 48 of 48, ATP Challenger qualifying 195 of 197, WTA 125 qualifying 61 of 63) and name the populations by tier rather than by "Challenger (men)" / "Challenger (women)", which the served fields do not distinguish.

No field, endpoint or behaviour changed; every correction is to a description.

Live Tennis API 1.13.40

2026-09-22T00:00:00Z

Added

tier and tier_source on every match and tournament object, with ?tier= on GET /matches and GET /history/matches. tier is the level the tournament was played at in the season of the match — the official category as the tour publishes it — and answers the question category cannot: is this a WTA 125, an ITF W35 or a Challenger 75? The vocabulary is closed: grand_slam; the ATP levels (atp_finals, atp_1000, atp_500, atp_250, next_gen_finals); the WTA levels (wta_finals, wta_elite_trophy, wta_1000, wta_500, wta_250, wta_125); challenger_175 … challenger_50; the ITF World Tennis Tour categories (itf_m15, itf_m25, itf_w15 … itf_w100, with the 2023 women's categories kept as printed that season); the team events (united_cup, davis_cup, bjk_cup, laver_cup, olympics); juniors; utr; exhibition; or null — nothing we hold names the level, never guessed. The tier is per season and it moves under one tournament_id: Dallas was atp_250 in 2023 and 2024 and atp_500 from 2025, so a 2024 Dallas match reads atp_250 and a 2025 one atp_500 under the same id. A match's tier is resolved by the calendar year of its scheduled_time, never copied from the tournament row; /tournaments rows carry the current season's, null when this season's calendar does not list the event. tier_source says how the level was established — calendar (the official per-season tour calendar), name (an unambiguous name rule: the ITF category is in the event's official name, team and UTR events are named as such), wikipedia (the season's schedule page, only where the official calendar could not state the level for that season), resolver (resolved after the seed dataset by the same rules) — and is null exactly when tier is null. The 2023–2026 seasons were verified event by event against the official calendars (99.1% of tournament-seasons resolved; the rest deliberately null). ?tier= takes comma-separated exact values, read from the same per-season table so filter and field cannot disagree; a null tier matches no value; an unknown value is a 400 bad_tier with the offending values in bad and the full vocabulary in allowed. category is unchanged and remains the coarse class.
A correction to a published result is signalled, never a silent edit: basis: restatement on the status history, result_restated_at / result_version on every match object, and ?restated_since= on GET /history/matches. Raised by a licensed results customer settling off our results. Once a match has been published as completed (or as a cancelled walkover with a winner), any later change to status, event_status, winner or the final score is appended to GET /matches/{matchId}/status-history as a new row with basis: restatement, at the instant we made the change: status / event_status carry before and after as usual (the same value twice when only the winner or the score moved) and score is the result after the correction. This holds for every path that can change a result — a source's late final, a second authority's correction, an operator's repair, a completion reopened and re-closed — because it is enforced where the result is written, not by each path remembering to say so; a re-assertion of the same result, or a change to points alone, writes nothing. result_restated_at is the instant of the newest such row (null while the result stands as first published); result_version is 1 plus the number of corrections — record it with the result you settle on, and a higher number on re-read means the one you hold was superseded. ?restated_since=<ISO instant> keeps only the matches corrected after that instant — the poll to run after each settlement pass; a Z or an offset, a naive value read as UTC, and a bare date refused as 400 bad_restated_since, because a day is not an instant. Rows with this basis exist from 2026-09-22; earlier corrections were not signalled and nothing is reconstructed for them.
winner on every row of every history tape: who won the point that produced the row. Raised by a modelling customer initialising serve states from the tape — server and serve were stated per row, and the third fact a model needs was only implicit in the score step. winner (1 | 2 | null) is judged from the score step between the row and the previous served row (the previous raw row on the raw sequence, the previous clean row under ?sequence=clean), by the same rule the completeness ledger counts a legal transition with — and from nothing else: never the serve, the server, the outcome tag or the pattern of play. Null on the first row and wherever the step is not one attributable point: a re-sent row, a set opener, a backward correction, a multi-game jump. A step whose games total rises by exactly one attributes to the side whose count rose — the game point was theirs — whatever in-game points the step skipped, a missed poll or a game withheld whole (meta.points.games_withheld). Present on the raw and clean sequences, on ?points=complete reads and on the pre-2023 archive tape; equal to point_winner wherever that older key is present, which is kept unchanged for existing readers. Derived once per response, never stored.
schema_version on the packages listing, and bulk tape rows carry the enriched tape. Under schema_version 2 a kind=tape JSONL line is exactly what GET /history/matches/{matchId} returns for that match on its default basis, produced by the same code — the same rows with origin, serve, outcome and winner beside the score columns, and the full meta (enrichment, reconstructed_at, observed_span, meta.points where served) — so a model reads its serve states from the bulk file just as it would from the endpoint; the CSV appends origin, serve, outcome, winner after danger, in that order, and its column order grows only at the end. 1 is the shape every month built before 22 September 2026 carries: score columns only, no meta.enrichment, and a CSV that ends at danger. Months built before that date keep shape 1 until they are rebuilt — newest month first, then backwards, built_at and sha256 moving as each flips — so check the manifest rather than assuming; a consumer that needs the enriched fields should require schema_version >= 2 and, for a month still at 1, read the per-match endpoint for the matches it needs. null on the non-tape kinds.

Changed

A completed match on the tours with a complete per-point record is re-joined after the match against that complete sequence. ATP 250/500/1000, ATP Challenger and WTA 1000/500/250/125: the live join paired serve / outcome onto points as they were captured, so a point tagged after our capture went untagged. A completed match is now re-joined against the complete sequence by the same exact-state rule, and its serve/outcome coverage exceeds what was captured live. The late tags arrive as point_update frames and tagged_at revisions like any other — collect them with ?changed_since=. Nothing is inferred; a point that is never stated stays null.
The pre-2023 archive tape no longer claims point_winner is null throughout a per-game tape. On a per-game tape (556 matches, 555 of them 2013) consecutive rows differ by a whole game, and the reference said no point was attributable there. Each row in fact reads the side whose game count rose — the game point was theirs — and says nothing about the game's other points; winner reads the same. No field changed shape or value.

Live Tennis API 1.13.39

2026-09-22T00:00:00Z

Changed

is_qualifying states the one case where a round label DOES decide the draw. The field said it is "never inferred from the round label", which is the right instinct and slightly too strong: main-draw vocabulary (Semi-finals, Final) is indeed never read that way, but a round label that itself reads Qualification Round 1 is STATING the draw, and it reads true — a false beside such a round is a payload contradicting itself rather than asserting main draw. Three matches (Chengdu, 22 Sep) were briefly served is_qualifying: false with round_code: "Q1" beside them and were repaired the same morning. Readers segregating a corpus by draw need to know which way that conflict resolves. No field changed shape or type.

Live Tennis API 1.13.38

2026-09-22T00:00:00Z

Changed

GET /markets states that the scope is MATCH-WINNER ONLY, and returns at most one market. A prospect asked whether the odds endpoints carry game spreads / handicaps (A -3.5 @ 1.90) in addition to match-winner prices. Every description in this reference already said "match-winner market", but nowhere said what that EXCLUDES, and the endpoint's own summary said "market(s)". Both are now explicit: no handicaps or game spreads, no totals, no set-winner books, no per-game or per-set derivative; data holds at most one object and meta.count is 0 when nothing is mapped. Venues do list tennis derivatives beside the match-winner book and this API publishes none of them — a derivative is refused at the mapping step. No field changed shape or value.

Live Tennis API 1.13.37

2026-09-21T00:00:00Z

Added

is_qualifying is documented on the match object. The field has been served on GET /matches, GET /matches/{matchId} and GET /history/matches for some time and was absent from this reference entirely, which left the one field that separates a qualifying draw from the main draw invisible to anyone reading the docs. Three-valued: true/false are the source's own assertion, null means no source has ever stated it, and null is not false.

Changed

round and round_code now state that they are DRAW-RELATIVE. Both describe the round *within* the draw the match belongs to, and the draw is named by is_qualifying — not by the round. A qualifying semi-final carries round: "... - Semi-finals" and round_code: SF, exactly as a main-draw semi-final does; Q/Q1..Q4 appear only where the label itself names the round as qualifying, which most labels do not. round_code previously said "this is the field to branch on" without that limit, and two customers independently read a qualifying match as a main-draw one and reported it as a data fault. The data was correct in every case; the documentation was not. No field changed shape or value.

Live Tennis API 1.13.36

2026-09-21T00:00:00Z

Changed

GET /charting/players states a sample of 11,803 charted matches, not 11,646. The charted corpus was refreshed on 2026-09-19 and 184 matches — 133 of them played after 2026-05-24, including the US Open women's draw to the quarter-finals — were loaded into the product on 2026-09-21. matches_charted on every response has always been the true per-player denominator and was never affected; the curated-coverage note beside it was quoting an older total and understating the sample. GET /rally/matches grew in the same load: 11,822 charted matches and 1,875,132 shot-by-shot points, with the newest women's chart now 2026-09-09. The men's corpus is unchanged because no men's match has been charted since 2026-05-21. No field changed shape.

Live Tennis API 1.13.35

2026-09-21T00:00:00Z

Added

meta.points.games_short on GET /history/matches/{matchId} counts the completed games the tape holds too few points for. Raised by a prospect evaluating per-point histories. A game the tape skips whole is a legal 0-0 → 0-0 boundary with the games counter up by one, and the transition test alone cannot see it — so a tape could read complete: true with a whole game missing. The measurement now walks the sequence by game boundary and compares what is held for each completed game with the fewest points that game can have contained given the last state it shows (from 0-0 at least 4; from 15-30 at least 5; from 40-40 at least 8; a tiebreak at least 7) — a lower bound, never an estimate. A game the tape skips whole counts; so does a game that ended with no further rows after its last stored point. > 0 forces complete to false; nothing is inferred or repaired, and the game's boundary rows are still served exactly as stored. null = nothing measured (an empty sequence).
basis_reason on GET /matches/{matchId}/points says why a reconstruction was served instead of the stream. Present on the reconstruction basis only: stream_absent (no stored stream rows), stream_incomplete (the stream is legal but does not measure complete — it joined mid-match or stopped short — and carries no tags) or stream_illegal (at least one transition is not attributable to one point: a gap or a torn row). A stream that is complete, or tagged and legal end to end, is always served on the live basis and the key is absent. Additive; nothing else in the response changes shape.

Changed

meta.points.complete now means the served sequence holds at least every point the score requires — not merely that consecutive rows are consistent with each other. True only when the sequence opens at 0-0, every transition is a legal single-point step, it carries at least as many point transitions as the final scoreline implies the match contained, every completed game holds at least as many point transitions as it must have contained (games_short is 0), it reaches a finished final scoreline at love (or the match ended early — retirement/walkover), it is not known-truncated, and no game was withheld (games_withheld). ends_at_final on the same object now also requires that the last row shows no game in progress — points at love or null, not a tiebreak in progress: a row carrying a finished spine with a game still underway ([[6,6],[3,4]] at 15-0) reads false, where before the spine alone decided. Some tapes that read complete: true until now will read false; no row is changed.
A recurring score state on the history tape pairs its serve/outcome by nearest clock, instead of reading null. Tags on GET /history/matches/{matchId} rows are joined from the match's per-point stream by exact score state, and a state the stream asserts more than once (a deuce cycle revisiting deuce) cannot be told apart by the score, so until now it read null outright. Where a state recurs the join now pairs by nearest clock within 90 seconds — the tape row's observed clock against the stream point's, each stream point used at most once — and reads null otherwise (no candidate within the window, or two at the same distance). Every tag is an observed pairing, state and where needed clock, never an inference from the pattern of play. Reconstructed rows and rows no stream point matches still read null.

Fixed

A stored live stream that is complete, or tagged and legal end to end, is served on a completed match; a reconstruction is projected only when the stream falls short. Until now a measured-complete recorded sequence displaced the stream unconditionally, so a completed match could lose its serve/outcome tags and every per-point clock the moment a reconstruction landed — a projection carries neither, so a complete tagged stream is strictly more information than any reconstruction of the same match. GET /matches/{matchId}/points now keeps the live basis whenever the stream is itself measured complete (match-closing point included) or carries tags and is legal end to end (every transition one attributable point, judged in playing order), and serves the projection only when the stream has no rows, is incomplete and untagged, or holds a transition nobody can attribute — basis_reason says which. When the reconstruction serves it still serves wholesale; the two sequences are never interleaved. If a completed match reads reconstruction, re-read from after_seq=0 rather than resuming a live cursor into it.
A double fault stated on a first serve is a contradiction; the point is served untagged. A source point whose serve number and outcome contradict each other — a double fault on serve 1 — was carried through as stated. serve and outcome on such a point now both read null on GET /matches/{matchId}/points and on the WebSocket frames rather than tagged wrongly; nothing is corrected to a second serve. Stored tags that carried the contradiction have been cleared.

Live Tennis API 1.13.34

2026-09-21T00:00:00Z

Changed

The reference said Davis Cup and the Grand Slams "read null throughout" for the per-point tags; serve is in fact stated on the top Davis Cup tiers. serve and outcome are stated separately, and the old sentence excluded both on the strength of one of them: team ties and Slams carry no per-point outcome, so outcome is genuinely null there — but the serve number is stated on them. Measured over completed matches with a per-point stream since 2026-09-12: Davis Cup World Group states serve on 22 of 22 matches and World Group I on 41 of 42, while World Group II states it on 0 of 38; outcome is null on all of them, on every one of the 14,132 rows. The machine-readable authority was right throughout and is unchanged — a World Group I match answers enrichment: {"serve": "stated", "outcome": "none"} and a World Group II match answers {"serve": "none", "outcome": "none"} — so this corrects the prose to match what the API already returns, in the direction of more coverage, not less. The serve description now names the Davis Cup tiers in its coverage list with the measurement; the outcome description now treats the two fields separately instead of excluding a competition from both. No field, endpoint or behaviour change.

Live Tennis API 1.13.33

2026-09-21T00:00:00Z

Changed

serve and outcome said nothing about qualifying or doubles draws, and the internal reference called both blanket-null. The per-point tags (added 2026-09-12) were documented tour by tour for main draws only. Measured over completed matches carrying a per-point stream since the source went live on 2026-09-12: WTA qualifying states serve on 48 of 48, Challenger (men) qualifying on 153 of 155, Challenger (women) on 49 of 51; ITF qualifying states outcome (aces and double faults) on 95 of 107 men's and 62 of 74 women's. Qualifying draws are covered like their own main draw, with exactly one real gap — outcome on Challenger (men) qualifying, which no source states at all. The doubles half of the old claim is confirmed and now carries its denominator: across 454 completed doubles matches in the same window, not one row carries either field. Both descriptions now state where each field is stated, including the qualifying and doubles positions; enrichment per match remains the authority and none of it is a promise about a match not yet played. Found by the every-sweep tag-coverage check, which reads 85 of 86 Challenger qualifying matches carrying serve against a documented null. No field, endpoint or behaviour change.

Live Tennis API 1.13.32

2026-09-21T00:00:00Z

Changed

A match that ends in a tiebreak closes with the set roll-up row after the decisive tiebreak score. The match-closing row on GET /matches/{matchId}/points was described as if the last point were always a game point one point short of the final, and a match decided in a tiebreak did not fit that shape. The docs now say what the stream actually holds: when a completed match ends in a tiebreak, the stream's last stored row is the decisive tiebreak score itself (7-3, or 8-6) and the closing row is the set roll-up after it — the next game number, number 0, tiebreak false, sets incremented for the tiebreak winner, the set banked 7-6 in games, score 0-0, server null, winner the tiebreak winner — the same row the stream stores after every other set-ending tiebreak, so ends_at_final reads true there. A 10-point match tiebreak still cannot be stated as one point and is refused as before (ends_at_final: false), as is a tape that never reached the final.

Live Tennis API 1.13.31

2026-09-20T00:00:00Z

Added

GET /matches/{matchId}/points now closes a completed match with the match-closing point, and ends_at_final says whether it did. Raised by a prospect evaluating per-point tapes, who asked where the point that wins the match is. Every row is the state *after* a point, so a game-winning point is carried by the next game's number: 0 opener — and the match-winning point had no next row to be carried by: the live stream never held it, and a serve statistic built off the stream was missing every match's last point. On a completed match served on the live basis the page now ends with one terminal row: seq = last + 1, number 0, sets / games the final score, score 0-0, tiebreak false, server null (nobody serves next), winner the match winner, ts the instant the final score was observed. It is built at read time from the stream's last row and the observed final score, and only when the two are one point apart; nothing is fabricated otherwise. ends_at_final (boolean) on the response says whether the sequence served ends on that row: false on a completed match whose stream stops short of it (a retirement or walkover, a capture that stopped two or more points short, a closer from deuce or from a match tiebreak that cannot be stated as one point), always false on a live match, and on the reconstruction basis judged from the projected sequence's last frame. serve / outcome on the terminal row are null: no source's tag for a match's last point is stored yet. WebSocket and push frames are unchanged.
tagged_at on every point row, and ?changed_since= on the same endpoint, so late serve/outcome tags are collectable without a socket. The same prospect asked how to pick up tags that land after a row was read. after_seq is a cursor by seq, so it can never return a row already held — and a serve / outcome tag that lands late lands on exactly such a row; until now the only way to see it was the point_update frame on a WebSocket. Every row now carries tagged_at, the UTC instant its tags landed (null while none has, and on every reconstruction-basis frame), and ?changed_since=<ISO-8601 instant> (2026-09-20T00:35:18Z; Z or an offset, a naive value is read as UTC, a date alone is refused) returns only the rows whose ts or tagged_at is later than that instant, in seq order, paged as usual and composable with after_seq. The post-match recipe: read the match, keep the instant, re-read with changed_since=<that instant> and replace held rows by seq. Anything that is not an ISO-8601 timestamp is a 400 bad_changed_since. On the reconstruction basis no row carries a clock or a tag, so a changed_since read of it is an empty page: that sequence is final at first read.

Live Tennis API 1.13.30

2026-09-20T00:00:00Z

Changed

The ATP per-point outcome row said "full" as a projection, not a measurement. In the 30 days since ATP per-point outcomes went live (2026-09-12), no ATP main-tour event was actually played — the only tour tennis in that window was a Grand Slam and Davis Cup, neither of which carries per-point outcomes — so every ATP main-tour match carried no outcome tags at all, while the docs asserted full (ace, double fault, winner, forced error, unforced error) unconditionally. The row now names the tours covered (ATP 250 / 500 / 1000), states plainly that Grand Slams and Davis Cup are not on it and read null throughout (check enrichment per match), and gives the first date the claim was actually measured against a played tour event: the week of 2026-09-22.

Live Tennis API 1.13.29

2026-09-20T00:00:00Z

Changed

The GET /history/matches listing's point-completeness ledger now judges the same raw sequence the per-match read serves, re-sent rows dropped — not the clean collapse. The ledger's previous default basis, clean, collapses the tape to one row per distinct score state; that collapse can delete a real deuce point — two rows sitting at 40-40 with no advantage row between them is a legitimate rally, not a duplicate — and call the resulting, shorter tape point-complete when the tape actually served is not. The ledger now judges the raw sequence with provable re-sends dropped, the exact judgement the per-match read makes and publishes as meta.points.complete, so tape.points_complete_default on the listing and meta.points.complete on a fetched match agree by construction instead of disagreeing on a sequence the read never served. Measured on 7,717 completed matches scored since 1 Sep: the clean collapse called 70 of them point-complete whose served (raw) tape was not, and missed 810 whose served tape was. clean remains available only as a request option (?sequence=clean); rows scored before 2026-09-20 keep points_basis: clean until the nightly re-score reaches them. tape.points_basis, tape.points_complete_default and tape.points_complete descriptions updated to match.

Fixed

tape.computed_at on the GET /history/matches listing carried the serving host's UTC offset (+03:00 on prod) instead of a trailing Z. Same instant, valid ISO-8601, but every other timestamp in the payload — meta.generated_at, each row's timestamp — ends in Z, so a consumer diffing computed_at against either had to normalise it by hand first. Now projected to UTC with a trailing Z like the rest of the surface.

{E(spec['info']['title'])} {E(e['version'])}

{e['date']}T00:00:00Z

{E(_md_block(e["body_md"]))}