Terms & Acceptable Use

What these terms cover

These terms govern use of the ThemeParks.wiki website and the free, public ThemeParks.wiki API (together, the "Service"). By using the Service you accept them.

The Service is operated by Jamie Holding (James Holding on the paperwork), a sole trader based in the United Kingdom trading as ThemeParks.wiki. That is who you are agreeing these terms with, and the registration and postal details are at the end of this page.

Paid commercial subscriptions, when they launch, will come with separate commercial terms and an availability SLA — see the reliability statement for how we run the service today.

Using the free tier

tl;dr — a wait-times app is exactly what this API is for. A mobile app, watch app, website, or dashboard that shows wait times to people is allowed and welcomed — free or paid, ads or no ads, no permission needed. Just show the "Powered by ThemeParks.wiki" credit. The one thing you can't do is pass the data on as data for other people's software to consume — running your own wait-times API, feed, or bulk download.

The free tier is open to personal, educational, research, and commercial use alike — building a commercial product on the free API is allowed and welcomed. All use is subject to one core line:

The data must be an input to your product, not the product itself. The test is who consumes the data downstream. If people read it in your app or site, it's an input — even if wait times are your app's whole point. If other people's software gets it from you (an API, a feed, a file), that's redistribution, and that's the part that isn't allowed.

So building a value-added application on top of the data is exactly what it's for: crowd calendars, forecasts, trip planners, guides, dashboards, wait-time predictions. Displaying the data to your own users inside such a product is expressly permitted, as is internal and analytics use, and short-term operational caching to serve your product.

What is not allowed

You may not:

• Resell or redistribute the feed as data — sell, sublicense, publish, mirror, sync, or otherwise make the data (or a substantial part of it) available to third parties as data, whether or not for a fee.
• Mirror, re-API, or re-stream — operate a service whose primary function is to relay the data (your own wait-times API built on ours, a near-verbatim mirror, or re-broadcasting a realtime stream). Embeddable widgets or iframes that place the data on third-party sites count as redistribution regardless of what else your service does.
• Offer bulk export — let your users or third parties extract a substantial, feed-like part of the data from your product. (Letting others pull every park's wait times on an ongoing basis crosses the line; a user saving their own trip plan, or a chart you generated from the data, does not.)
• Circumvent rate limits or key authentication — including rotating IP addresses or sharing/pooling keys to evade per-client limits.
• Scrape the website abusively where the API serves the same data — the API exists so you don't have to.
• Pass the data off as official park data, or imply that any park, operator, or ThemeParks.wiki endorses or is affiliated with your product.

Redistribution — providing the feed to others as data — isn't permitted on any tier; the paid tiers buy premium delivery and archive access, not the right to redistribute.

Attribution

If your product presents the data to your own users, it must display attribution: a clear, visible "Powered by ThemeParks.wiki" credit linking to themeparks.wiki. This is the deal for free commercial use.

On surfaces where a link isn't possible (watch faces, complications, voice), a credit in your app's about or settings screen — or its store listing — satisfies this.

Paid subscriptions, when they launch, will include the right to skip the credit (white-label) under their commercial terms — payment replaces it.

For internal tools, research, and projects only you use, attribution is requested but not required. Supporting the project as a GitHub sponsor is appreciated but never required, and it doesn't gate access to the data.

Rate limits & fair use

• These limits apply to the REST API. Requests are counted per API key where one is sent, otherwise per IP address — a limit, not a target. Specific figures are deliberately not stated here, so that this page cannot fall out of step with what the API actually enforces. If and when tiers with published limits are offered, those figures will be published on this website.
• Websockets are limited separately and do not count towards the REST limit. Each tier sets a maximum number of concurrent connections and a maximum number of entity subscriptions per connection, and firehose access is a per-tier flag.
• Limits are set per interface. Any other API surface offered in future will be limited separately again, and its limits published in the same way.
• Server data is refreshed every few minutes and cached, so there's no point polling live data more than once every 5 minutes — faster requests just return cached results. Polling every park's live data on that cadence sits well within the limit.
• Exceeding the limit returns HTTP 429 with a Retry-After header (seconds to wait). Handle 429s gracefully.
• The data is free. Paid tiers, when they launch, will sell premium delivery — higher rate limits and realtime push over websockets — not different or extra live data: the live feed is identical on every tier. Limits may be adjusted with load.

The free tier floor

The free tier's current limits are published on the API documentation page. They are kept there, not here, so that this page cannot fall out of step with what the service actually offers.

For existing account holders, those limits only ever move up. We do not narrow the free tier for accounts created before a change: if a published free-tier limit is reduced, the reduction applies only to accounts created on or after the date of that change, and an account opened under a more generous limit keeps it.

Changes to the free tier's limits are dated and logged in the changelog below.

Free tier changelog

• 17 August 2026 — clause introduced.

Historical data & caching

Short-term operational caching to serve your product is fine, and derived or aggregated analysis you build from the data — trends, statistics, forecast models — is yours to keep and use, provided a substantial, feed-like part of the data can't be extracted back out of what you publish. That includes recording your own history from the live feed to power your own product.

What's not permitted is building a persistent, standalone copy or mirror of the dataset to redistribute as data. The live data is free to use as above; our historical archive — the maintained back-catalogue of past wait times and schedules — will be a paid product when the commercial tiers launch. Need deep history, higher limits, or realtime push today? Email cube@themeparks.wiki.

API keys

Most endpoints are public. Some require an API key sent in the x-api-key header. You can create one or more named keys from your profile. Creating an API key means you accept these terms.

• Keys are shown once at creation — the server stores only a one-way hash and the public prefix, and cannot recover a lost key. Create a new one and revoke the old.
• Keep keys secret. You are responsible for all use of the Service under your key.
• Keys and accounts may be revoked or suspended for abuse or breach of these terms.

AI & ML training

• Permitted: training models that power your own product — for example a wait-time prediction model inside your application.
• Not permitted: training or distributing a model or dataset that reproduces or substitutes for the feed — anything from which the data, or a substantial part of it, can be extracted in feed-like form counts as redistribution.

Data rights

ThemeParks.wiki claims rights in its compilation, normalisation, and service — the aggregated, structured feed, the entity model, the API, the SDKs, and the website. This compilation — in particular our historical archive, which ThemeParks.wiki compiles, verifies, and maintains through substantial and ongoing investment — may be protected by database rights and similar laws in some jurisdictions. Some underlying facts come from upstream sources under their own licenses; where those apply, their attribution carries through.

The parks and operators own the underlying data and their trademarks. We do not claim ownership of wait times, schedules, or park and attraction names, which appear for identification only. ThemeParks.wiki is not affiliated with, endorsed by, or sponsored by any park or operator, and your use of the Service creates no such relationship for you.

These terms grant a limited, non-exclusive, non-transferable, revocable permission to use the Service as described here. You acquire no ownership of the data or the feed.

No warranty & liability

The Service and the data are provided "as is" and "as available", without warranty of any kind — including accuracy, completeness, freshness, or availability. Wait times are estimates that originate from the parks' own systems and can be wrong, stale, or missing. The free tier carries no SLA (see the reliability statement).

Do not rely on the data for safety, medical, accessibility, or operational decisions. It is planning-convenience data, nothing more. To the maximum extent permitted by law, ThemeParks.wiki is not liable for any indirect, incidental, or consequential loss arising from use of the Service.

Nothing in these terms excludes or limits our liability for death or personal injury caused by negligence, for fraud, or for anything else that cannot lawfully be excluded or limited. If you are a consumer, you keep every statutory right the law gives you, and nothing here affects them.

Continuity

ThemeParks.wiki is run by one person. If it ever winds down, my intention is to give as much notice as circumstances allow, and to release the historical archive openly rather than let it disappear. These are best-efforts commitments — I can't promise what I can't foresee.

What I can say for certain: the collector library (parksapi) is already open source, and that doesn't change. And if the service ever changes hands, I'll do everything in my power to make the existing commitments part of that deal.

The legal bits

• Severability: if any part of these terms is held invalid, the rest stays in force.
• Entire agreement: these terms — together with any separate commercial terms where they apply — are the whole agreement between you and ThemeParks.wiki for the Service.
• Termination: we may suspend or end access for breach. The parts that should outlast the agreement by their nature — data rights, the liability limits, and governing law — survive termination.
• No waiver: if we don't enforce a term straight away, that isn't us giving it up; we can still enforce it later.

Governing law

These terms, and any dispute arising out of them or the Service, are governed by the laws of England and Wales. Disputes are subject to the non-exclusive jurisdiction of the courts of England and Wales — "non-exclusive" meaning you may also bring a claim in your own local courts where the law lets you.

Changes & contact

The Service evolves. Additive API changes may happen at any time; for breaking changes to v1 our intent is to give advance notice with a migration path (see the reliability statement). We may update these terms; material changes are announced on the status page, recorded in the dated changelog below, and, for account holders, sent by email. Changes apply from the date of their changelog entry, never retroactively; if you don't accept a change, your remedy is simple — stop using the Service and revoke your keys.

Questions about these terms: cube@themeparks.wiki. What we do with your personal data is a separate document: see the privacy notice.

• Postal address: James Holding, ThemeParks.wiki, 27 Old Gloucester Street, London, WC1N 3AX, United Kingdom. Post needs the name James on it to reach us.
• ICO registration: ZC215410, on the Information Commissioner's Office register of fee payers. It is a public entry, so you can check who you are dealing with without asking us.

Changelog

• 9 August 2026 — named the operator, and added our postal address and ICO registration number. No change to any term.
• 27 July 2026 — noted that paid subscriptions will include a white-label (no credit) option.
• 26 July 2026 — first published.