Reliability

What this is

ThemeParks.wiki is a free, real-time API for theme-park wait times, schedules, and live data worldwide, plus the website built on it. It is free to access and most endpoints require no API key. It is run on a best-effort basis — but "best effort" here means run seriously: the service has operated continuously for years, powers real products, and we treat it like production infrastructure, because for the people building on it, it is.

This page exists so you can make an informed decision about depending on us. If you need contractual guarantees, an availability SLA comes with the Business and Enterprise plans — see Uptime below.

Data freshness

• Server data is refreshed every few minutes and cached.
• We recommend polling live data no more than once every 5 minutes. Requesting more frequently will likely just return cached results — it costs you requests and gains you nothing.
• Wait times originate from the parks' own systems. We relay them quickly and faithfully, but we cannot make upstream data fresher or more accurate than the parks publish it.
• What we have actually recorded, park by park and field by field, is published on the data coverage page — including how far back each park goes and when it was last added to. This page is about the service; that one is about the data.

API stability

• v1 is stable. We do not break it casually. Entity IDs are stable identifiers — you can safely store them long-term.
• Additive changes (new fields, tags, entity types, endpoints) may happen at any time. Build your client to ignore fields it doesn't recognise.
• Breaking changes: our intent is to announce any breaking change to v1 at least 6 months in advance, with a migration path, and to run old and new behaviour side-by-side where practical.

Uptime vs. data freshness

"Uptime" means our service responding — the /v1 REST API and the websocket service, the parts we build and run. This website is not part of it.

The availability SLA measures the same two things, as one figure. The status page probes both: GET /v1/entity/{id}/live for the REST API, and a real websocket connection — opened, authenticated, waited on for the welcome frame — for the live feed. A minute counts as down if either fails, so a websocket-only outage costs the published figure exactly as a REST outage does. The availability SLA is assessed on that figure and expressly excludes this site, the API documentation, and the account pages. Live-data freshness is monitored too and deliberately left out of the figure: it measures whether the parks are still sending us anything, which is upstream of us. On the free tier we make no numeric promise: the free tier carries no uptime SLA. In practice the service is almost always up, but on the free tier you should not represent an SLA to your own users.

Data freshness is a separate thing, and it depends on the parks. Their systems go down, change, or rotate credentials, so a park's wait times can be stale or missing even when our API is fully up — that is upstream, not our service being down. Every live record includes a lastUpdated timestamp, so you can always see exactly how fresh each value is and handle staleness in your own product.

If your business needs contractual guarantees, that is what a paid subscription is for. Business carries a 99.5% monthly availability commitment and Enterprise 99.9%, with service credits as the remedy. Those two figures are contractual for the plans that carry them, and the availability SLA in our terms is the authority for them — not this page, which states them for orientation. The first assessed month for Business is October 2026. Read it with the paragraph above: it covers our service responding, and it is not a guarantee of the parks' data being complete, fresh, or accurate. Nothing there changes the free tier, which carries no SLA.

How we communicate changes and incidents

• Status page: status.themeparks.wiki — the canonical place for live service status, incident history, and breaking-change announcements.
• Development happens in the open on GitHub — the ThemeParks organisation hosts the data-collection code (parksapi) and the official SDKs; breaking changes are echoed there too.

Reporting problems

• Data problems (stale or wrong wait times, missing parks or attractions): open an issue on github.com/themeparks/parksapi.
• SDK problems: open an issue on the relevant SDK repository in the ThemeParks GitHub organisation.
• Anything else / private reports (security issues, terms questions): hello@themeparks.wiki.

Good bug reports with entity IDs and timestamps get fixed fastest.