History¶
Reached as tp.entity(id).history. Both methods page for you and yield rows
as they arrive, so a resort's five years never has to fit in memory.
Ask a park id wherever you can. Both history endpoints answer a whole park in one request, and a park-by-park backfill of a large resort costs around a hundred times fewer calls than the same data fetched ride by ride.
History for one entity id, reached as tp.entity(id).history.
coverage ¶
What history exists here, field by field. Ask this before a backfill.
span ¶
The dates a backfill should run between, as a :class:HistorySpan.
One call, and the same three fields whether this id is a park or a single ride.
days ¶
days(start: str | date | None = None, end: str | date | None = None, *, max_wait: float = DEFAULT_MAX_WAIT_SECONDS) -> Iterator[tuple[str, HistoryDailyRow]]
One summary row per park-local day, as (entity id, row).
Pages automatically. Given a park id this uses the park call, which answers every entity in the park in one request.
changes ¶
changes(date: str | date | None = None, *, start: str | date | None = None, end: str | date | None = None, max_wait: float = DEFAULT_MAX_WAIT_SECONDS) -> Iterator[tuple[str, HistoryRow]]
Every recorded change, as (entity id, row).
A single day for a park, or up to 31 days for one entity. The caller does not have to know which cap applies: ask for what you want and the API answers or tells you the range is too long.
Bases: RateLimitError
The hourly history budget is spent and the wait is longer than allowed.
Carries retry_after from the underlying 429, so a backfill can record
where it got to and resume after that long rather than holding a process
open waiting for a budget window to roll.