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, commercial terms with an SLA are planned — 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.

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 API and website responding — the part we build and run. 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 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 the planned commercial terms are for. They are not available yet; when they are, an availability SLA will be part of them.

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): cube@themeparks.wiki.

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