ActorStack.dev

A full tennis season is 148,000 matches and about $56

History goes back to 1995 with the same input. What a season actually costs, why the price has two tiers, and the settings that decide how long it takes.

By Oswaldo Carabano6 min read

Short answer

A full tennis season is about 148,000 matches — measured, not extrapolated — and costs roughly $56 to backfill, because the first 10,000 rows of a run are $0.0015 each and everything after that is $0.0003. A week of results is about $4. History goes back to 1995 with the same input shape, so a backfill is a wider date range rather than a different mode, and the whole 1995 to 2026 archive is around 2.4 million matches. One request covers one calendar day, so a season is 365 requests before any enrichment.

Key points

  • One request per calendar day, so a season is 365 requests and the whole archive about 11,000.
  • About 148,000 matches in a season, measured across a full year rather than extrapolated from a week.
  • Two price tiers within a single run: $0.0015 for the first 10,000 rows and $0.0003 after that.
  • The tiering is per run, so splitting a backfill into many small runs costs more than doing it in few large ones.
  • `maxItems` defaults to 10,000, which is exactly the first tier — raise it before starting a backfill or the run stops at the tier boundary.
On this page6 sections

Historical tennis data is the case this Actor's pricing was shaped around, so it is worth setting out the arithmetic before starting a run rather than after.

How big the archive is

SpanMatchesRequests
One day150–6001
One week~2,8007
One season~148,000365
1995–2026~2.4 million~11,000

The season figure is measured across a full year rather than extrapolated from a busy week, which matters because the tennis calendar is not evenly distributed.

Two tiers, and why they exist

$0.0015 per row for the first 10,000 rows of a run, $0.0003 after that. A flat rate would have made a season cost about $222; the tier makes it about $56. The reason to structure it that way is that a backfill is a different kind of purchase from a daily monitoring run, and pricing them identically means one of the two is priced wrong.

The tiering rewards fewer, larger runs

The default that will stop your backfill

maxItems defaults to 10,000 — exactly the size of the first tier. Left alone, a historical run stops at the moment the price was about to drop by a factor of five. Raise it before starting.

Making it finish in reasonable time

maxConcurrency defaults to 8 and caps at 16, which is the highest level actually measured against the site. It is also capped by the memory the run was given: a 512 MB run tops out around 10, so a backfill should be given 1024 MB or more if it is expected to go fast.

A worked example

input.json — one season
{
  "entityType": "results",
  "dateFrom": "2025-01-01",
  "dateTo": "2025-12-31",
  "maxItems": 200000,
  "maxConcurrency": 16,
  "includeMatchDetail": false
}

365 requests, about 148,000 rows, about $56. Adding match detail would add roughly 148,000 requests and $355 in surcharges, which is the calculation that decides whether you need surface and round badly enough.

Frequently asked questions

How much does a season of tennis history cost?
About $56 for roughly 148,000 matches. The first 10,000 rows of a run cost $0.0015 each and the rest cost $0.0003, which is what makes a backfill affordable rather than a research budget.
How far back does the data go?
To 1995. The same input shape works for any past date, so backfilling is a matter of widening the date range. The whole archive is roughly 2.4 million matches.
Should I split a backfill into small runs?
No. The cheaper tier starts after the first 10,000 rows of each run, so many small runs pay the higher rate repeatedly. Fewer, larger runs are cheaper for exactly the same data.
Why does my backfill stop at 10,000 rows?
Because `maxItems` defaults to 10,000. It is a hard cap on delivered rows and it happens to coincide with the first pricing tier. Raise it before starting a historical run.

Sources

Every URL below was requested and returned a page on the date shown.

  1. Operator claimchecked 9 Sept 2026
    TennisExplorer Scraper — Actor README and input schemaActorStack / Apify Store
Two players mid-rally on an indoor clay tennis court during a competitive match.
TennisExplorerGuide

Scrape tennis results

A walkthrough of extracting tennis data: one entity type per run, the day boundary that has to be pinned, and the two enrichments that cost an extra request each.

8 min
A desk with stacked legal reference books, loose documents and a newspaper.
TennisExplorerExplainer

Why odds are off

The same results page carries match scores and bookmaker odds, and the two sit in different positions. Why one is on by default and the other is not.

5 min
A laptop screen showing a plain text-mode terminal with a command prompt.
TennisExplorerExplainer

The tennis API question

The tours publish rankings and draws for readers, not as APIs. Commercial feeds are licensed per use. What is left is reading a results site, and what that does and does not entitle you to.

7 min