Player profiles are the entity type where a cost decision and a privacy decision both show up in the input schema.
Where the player list comes from
Either explicitly, through playerUrls, or implicitly: leave it empty and the Actor takes the players from the ranking table selected in the same input. The second is usually what you want, because assembling a few hundred profile URLs by hand is the part of this job nobody should be doing.
Match history, priced per season
playerMatchHistoryYears defaults to 0, which reads the profile only — one request per player. Each additional season is one additional request per player, so the arithmetic compounds:
| Players | Years of history | Requests |
|---|---|---|
| 100 | 0 | 100 |
| 100 | 5 | 600 |
| 500 | 10 | 5,500 |
The reduction for players under 18
Players under 18 are returned with birth_year rather than a full birthdate, and without a photo URL. The source publishes more than that; the Actor returns less.
Why a reduction gets documented
Because a field that is missing for a reason and a field that is missing by accident look identical in a dataset. Somebody who finds a null birthdate and assumes a scraping failure will go looking for a fix that does not exist — and somebody building a downstream product needs to know that this data was deliberately reduced rather than incompletely collected.
The same principle governs the rest of this catalogue: a limit that is chosen gets written down next to the limits that were imposed.
