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 subscriptions are covered by the section of that name below. Enterprise arrangements are negotiated separately and have their own agreement. See the reliability statement for how we run the service.

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 is not something a self-serve plan can buy. Providing the feed to others as data is not permitted on any self-serve plan — any plan you can buy for yourself through checkout on this website, which today means the free tier, Pro, and Business — at any volume, and that stays true of any self-serve plan we add later. Those plans buy premium delivery and archive access, not the right to redistribute, and paying for more of them does not change that.

The one exception is named, revocable and in writing. Redistribution can be negotiated case by case under an Enterprise agreement. Such an exception is specific to the parties who sign it, names what may be redistributed, and is revocable under the terms of that agreement. It is not a right that attaches to the Enterprise plan, and it is not something Enterprise customers have by default. Without that written exception, everything in this section applies in full.

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.

This includes AI assistants and agents. An assistant, chatbot or agent that answers its users with the data is presenting it to them, so the answer carries the credit, linked where the surface allows a link. Scraping these pages instead of calling the API does not change that.

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 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 against your account when you send an API key or are signed in, so several keys on one account share a single allowance; requests with no key are counted per IP address, which you may be sharing. It is 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: the figures for every plan are published on the pricing page, generated from the catalogue the API enforces.
• 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 buy 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.

Paid subscriptions

Paid subscriptions are bought through checkout on this website. The checkout, payment, invoicing, tax and refunds are run by Paddle, our merchant of record: you buy the subscription from Paddle, which resells it to you under Paddle's buyer terms, and we supply the service to you under these terms. Paddle calculates and collects any VAT or sales tax that applies where you are, and issues your invoice.

A subscription gives you the features and limits published for that plan on this website when you buy — today, deeper access to the historical archive and the option to drop the "Powered by" credit — on top of everything the free tier offers.

• Renewal and cancelling: a subscription renews automatically at the end of each billing period, monthly or yearly as you chose, until you cancel. You can cancel at any time from your profile or through Paddle; cancellation takes effect at the end of the period you have already paid for, you keep access until then, and nothing further is charged.
• Price lock: The price you subscribe at is the price you pay for as long as you stay subscribed. The lock covers the price, not what a plan includes: we may change what a plan includes going forward, and the free tier floor above protects anything already published.
• Refunds: set out in the Refunds section below — 14 days on your first payment if you have not used the paid features; if you have, it depends which kind you used, because what you download is delivered when you download it while continuing access is refunded for the part of the period you have not had. Always refunded when the failure is ours.
• When a subscription ends, what you built from the data stays yours under the same rule as everything else on this page: an input to your product, never redistributed. You can keep the historical data you downloaded while subscribed, for your own internal use. It was delivered when you downloaded it, so nothing has to be deleted when the subscription ends, but it may not be redistributed, as “What is not allowed” describes. Some refunds, and a payment reversed through your card issuer, bank or payment provider, are different; the Refunds section says which, and what has to be deleted.

Access starts at once, and what that means if you change your mind. A subscription is switched on the moment it starts. You do not wait 14 days for it, and by subscribing you are asking us to begin supplying it straight away. In exchange you accept that using the paid features ends the 14-day right to change your mind about what you have used. A plan buys two different kinds of thing, and they do not work the same way here, so both are set out plainly:

• What you download is delivered when you download it. History beyond the free window is today's example. Once you have retrieved it, it has been supplied, and the 14-day right stops covering it. The law only lets us hand it over inside those 14 days if you have accepted that, and starting a subscription is you accepting it.
• Continuing access is supplied over time. The firehose, the higher limits and anything else your plan keeps giving you arrive across the period you paid for, not in one go. Using them does not end your 14-day right. Change your mind inside the window and we keep only what matches the part of the period you have already had, and refund the rest.

None of this takes a right away from you. It is how the 14-day right works when you ask for supply to start immediately, which is your choice to make and what the law provides for. The Refunds section below is the same rule from the other side, with how to ask.

Availability SLA

Who gets one. An availability SLA comes only with the plans this section names: Enterprise, and Business from 1 October 2026 (see "When it starts" at the end of this section). Every other plan carries no SLA and no service credits — today that is the free tier and Pro, and it is the default for any plan added later unless this section is amended to name it. Those plans are provided on the best-effort basis described in the reliability statement.

What we commit to. On Business, 99.5% monthly availability. On Enterprise, 99.9%, set in the Enterprise agreement; where that agreement and this page differ, the agreement prevails.

What is covered. The /v1 REST API and the live websocket service — the two things we build, run and measure. Nothing else is in scope: not this website, not the API documentation, not the account or admin pages, and not the status page itself.

The two are measured as one figure, and that works against us. The status page probes both, and a minute counts as down if either is down. So a websocket outage costs the same as a REST outage even for a customer who only uses REST, and the figure you are shown is the worse of the two rather than an average of them. We would rather publish one number that cannot flatter us than two that can be quoted selectively.

What is not covered, and this is the part to read twice. This SLA is about our service responding. It is not a promise about the theme-park data itself. Parks' own systems go down, change without notice, or return nothing, so a park's wait times can be stale, wrong, or missing while our API is fully up and inside its SLA. That is upstream of us and outside our control. There is no guarantee of data completeness, freshness, or accuracy on any tier, paid ones included. Every live record carries a lastUpdated timestamp, so you can see how fresh each value is for yourself and handle staleness in your own product. The reliability statement sets the same distinction out at length, and this section should be read with it.

What is excluded from the calculation.

• Scheduled maintenance announced in advance on the status page.
• Emergency maintenance carried out to apply a security fix.
• Force majeure, and failures in networks, hosting, or other providers outside our control.
• Suspension of your access under these terms, for breach or for non-payment.
• Downtime caused by your own use, including exceeding the rate limits your plan buys.

How it is measured. By our own service monitoring, published at status.themeparks.wiki, as a percentage of each UTC calendar month. The figure we publish there is the figure this SLA is assessed on, exactly as published: it is shown to four significant figures, and that published figure is what a month is judged against.

Service credits. If we miss the commitment for a UTC calendar month, the remedy is a credit against a future invoice, as a percentage of that month's subscription fee. On an annual subscription, one month's fee means one twelfth of the annual fee — not the annual fee itself. It is a credit, not a cash payment, with one exception: if your subscription has ended and there is no future invoice to credit it against, we pay it out instead. A credit you have earned is not lost because you cancelled.

Only the single highest band that applies is credited; the bands are not added together. Total credits for any one month cannot exceed 100% of that month's fee. You have to claim, by email to hello@themeparks.wiki, within 30 days of the end of the affected month; a credit not claimed within that time lapses.

Service credits are your sole and exclusive remedy for missed availability, with one express exception: the refund promised in Refunds where a prolonged outage, or a defect we cannot fix in a reasonable time, stops you using what you paid for. That promise stands. This section does not withdraw it and does not narrow it.

You can have the refund or the credit for the same outage, not both. Where we have already credited you for a period and you are then refunded for that same period, the credit counts towards the refund and we pay you the difference. One recovery for one outage, by whichever route fits your case better — never two stacked on each other, and never less than the larger of the two.

Our overall liability is capped: see the cap in "No warranty & liability" below, which service credits count towards. Nothing in this section affects any statutory right you have.

When it starts. This SLA applies to Business subscriptions from 1 October 2026. The first assessed month is October 2026. A subscription bought before that date is not assessed for the remainder of the month it was bought in, because we will not claim cover for a part-month we never measured; the guarantee begins with the first whole month. Enterprise availability runs from the date set in the Enterprise agreement.

Refunds

The short version: within 14 days of your first payment and you haven't used the paid features, full refund, no questions. Used them: what you downloaded is delivered and stays paid for, the part of the period you haven't had yet comes back, and we look before we decide. Renewals: cancel instead. Our fault: refunded whatever the date. If a refund is at your request or the payment is reversed, you delete what you retrieved in the period it covered; if it is for our fault or for access you did not use, you keep what you downloaded. Ask Paddle, or ask us.

Change of mind: 14 days on your first payment. If you start a subscription and decide it isn't for you, the first payment is refunded in full provided you ask within 14 days of making it and you have not used the paid features. "Used" means anything your plan gives you that the free tier does not — today, history beyond the free window and the websocket firehose. Creating a key, reading the docs and making requests the free tier also allows do not count. Nor does the route matter: requests made with an API key and requests made while signed in on this website count the same. Access starts as soon as the subscription does, and the clause on immediate access above says what that means; the two are one rule seen from two sides, not two rules.

If you have used the paid features, what happens next depends on which of them you used, because they are not the same thing in law. Anything you download is delivered the moment you retrieve it. Continuing access — the firehose, the higher limits, anything your plan keeps giving you for as long as it runs — is delivered gradually, across the period you paid for.

• What you downloaded. A few requests while evaluating the service is not what this is for, and we'll refund. Pulling a large slice of the historical archive is different: the archive is the product, and once retrieved it has been delivered, in the same way a downloaded file has, so the payment stands.
• Continuing access. Using it does not use it up, and we will not refuse a refund on the grounds that you connected. Ask inside the 14 days and you get back the part of the period you have not yet had; we keep the part you have. Once a period has run in full it has been supplied in full, and there is nothing left in it to refund.

Where a case sits between the two, a refund is at our discretion, decided on what the account actually did, whether through an API key or signed in on this website. That discretion runs one way only: it can add to what you are owed, never subtract from it. Paddle's own refund policy separately refuses refunds where there is evidence of fraud or refund abuse.

Renewals. A renewal payment is not eligible for a change-of-mind refund; the way to avoid one is to cancel before it falls due, and you keep access to the end of the period you paid for. If a renewal catches you out and the account has been idle for the whole of the previous period, email us: we would rather refund than argue about it.

When it's our fault. A prolonged outage, a defect that stops you using what you paid for and that we cannot fix in a reasonable time, or a feature you bought being withdrawn, each gets a refund of the affected period, in full or pro rata as fits, with no 14-day limit. Tell us at hello@themeparks.wiki first so we have the chance to fix it; the reliability statement says what we aim for.

How to ask. Paddle handles the money, so a refund request goes to Paddle: use the link in the receipt email Paddle sent you, or go to paddle.net, find the purchase and choose "Request refund". Or email us and we'll raise it with Paddle for you. Paddle may check with us about usage before approving. Approved refunds go back to the original payment method, usually within a few working days, and Paddle sends a credit note.

Businesses and consumers. The 14-day right to change your mind is a statutory right for consumers in the UK and EU; a business buyer has no such right in law. We apply this section to everyone the same way regardless: the same window, the same use test, the same discretion. Nothing here reduces any statutory right you have.

After a refund, or if the payment is reversed, your access ends at once: your account returns to the free tier and your keys keep working within its limits. What the free tier already lets you keep is unaffected. What happens to the history you downloaded depends on what was refunded or reversed, as the next two paragraphs say.

What you must delete. If a payment is refunded because you changed your mind or at our discretion, or is reversed through your card issuer, bank or payment provider (a chargeback or a payment dispute) and not reinstated, the money for that period has gone back to you, so you must delete the historical data you retrieved in the period that payment covered, and anything built from it from which a substantial part of that data could be extracted. A period is counted by the day you retrieved the data, not the dates the data describes. That holds for a reversal that happens after your subscription has ended, too. A dispute that is still open does not count until it is decided against the payment, and a payment is reinstated if the dispute is decided in our favour, you withdraw it, or the money is returned.

What you can keep. Data you retrieved in any other period, whose payments were not refunded or reversed, stays yours to keep, including data you retrieved again in such a period. A refund of unused continuing access only (the part of a period you have not had), a refund because of our fault (a prolonged outage, a defect we cannot fix, a feature you bought being withdrawn), a refund because the service winds down, or a service credit, does not end your right to keep what you downloaded, under the rule in Historical data & caching.

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.

History you downloaded under a paid plan can be kept. It was delivered when you downloaded it, so when the subscription ends you may keep that data for your own internal use. Internal use means use by you, or by your own staff if you subscribed for a business, and by the services that host, store or process the data for you; it does not include giving the data you downloaded to anyone else to use for their own purposes, and it may not be redistributed, as “What is not allowed” describes. Some refunds, and a payment reversed through your card issuer, bank or payment provider, are different: see Refunds. The caching rule above is about serving your product, not about data you downloaded.

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 — is a paid product. Need deep history, higher limits, or realtime push? See plans and prices, or email hello@themeparks.wiki if none of them fit.

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, and the key form asks you to confirm that by ticking the box; we keep a record of which version you accepted.

• 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).

One express exception, and only one: availability, on the plans that buy it. Where a subscription carries the Availability SLA above, that section is a contractual commitment about our service responding, and this disclaimer yields to it to that extent and no further. Everything else here stands in full on every tier, paid ones included: in particular the accuracy, completeness and freshness of the park data are disclaimed on every tier, and no SLA changes that.

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.

A cap on what we can owe you. To the maximum extent permitted by law, our total liability to you for any and all claims arising out of or in connection with these terms or the Service, whether in contract, tort (including negligence), misrepresentation, breach of statutory duty or otherwise — added together, not counted one claim at a time — is limited to the fees paid for the Service in the twelve months before the claim arose. That means the fees paid for your subscription however they were collected and whoever collected them — including the fees you paid through Paddle, which is how every subscription on this website is in fact bought. It does not include VAT or any sales tax charged on top of those fees: Paddle collects that and remits it to your tax authority, not to us. Service credits given under the Availability SLA count towards that limit. If nothing has been paid for the Service, the limit is nil. That is the position on the free tier, and we would rather say it here than have you discover it in a dispute. The cap is subject to the paragraph below: it does not reach liability that cannot lawfully be limited.

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 find a home for the historical archive rather than let it disappear. These are best-efforts commitments — I can't promise what I can't foresee.

One thing here is not best-efforts. If the service wound down while you were subscribed, the unused part of what you paid comes back to you. That is a commitment rather than an intention: it is the Refunds rule applied to the one case where there is nothing left to put right.

What I can say for certain: the data fetching 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: hello@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

• 21 October 2026: Refunds now says which refunds mean deleting the historical data you downloaded. The page used to say that after any refund you must delete all the historical data you had retrieved. Now it follows the payment: if a payment is refunded because you changed your mind or at our discretion, or reversed through your card issuer, bank or payment provider (a chargeback or a payment dispute) and not reinstated, you delete the historical data you retrieved in the period that payment covered, and you keep what you retrieved in any other period. A refund of unused continuing access only, a refund because of our fault or because the service winds down, and a service credit do not end your right to keep what you downloaded. Two things are now defined. Internal use means use by you, or by your own staff if you subscribed for a business, and by the services that host, store or process the data for you; it does not include giving the data to anyone else to use for their own purposes. A reversed payment now covers your card issuer or payment provider as well as your bank, and a reversal after your subscription has ended. Two parts of this are narrower for some buyers: those extra routes now mean deleting, and internal use now has a definition. The wider description of a reversed payment applies to payments made on or after 21 October 2026. The change is in Paid subscriptions, in Refunds, and in “Historical data & caching”. No change to the free tier, to who can get a refund, or to the SLA.
• 18 October 2026: said what happens to the historical data you downloaded when a paid subscription ends other than by refund or a payment reversed through your bank. You may keep those files for your own internal use; nothing has to be deleted, and the rule against redistributing them is unchanged. The change is in Paid subscriptions, in Refunds, and in “Historical data & caching”, whose mention of short-term operational caching could be read as ruling out keeping raw files at all. It is about caching to serve your product, not about files you downloaded. A refund still requires deleting what you retrieved, as Refunds says, and a payment reversed through your bank (a chargeback or dispute) is now treated the same way. This widens what you may do and takes nothing away from anyone who cancels normally: Refunds already treated what you download as delivered when you download it. No change to the free tier, to who can get a refund, to the SLA, or to anything else you may not do.
• 30 September 2026: Attribution now says in words that it covers AI assistants and agents. An assistant, chatbot or agent that answers its users with the data is presenting it to them, so the answer carries the "Powered by ThemeParks.wiki" credit, linked where the surface allows a link, and that holds whether the data came from the API or from scraping these pages. The rule is the one that was already there, stated for a kind of product it had not named. Paid plans keep the right to drop the credit, and internal tools and projects only you use are still asked, not required, to show it. No change to the free tier, to refunds, or to the SLA.
• 28 September 2026 — paid plans are open, so the three sentences that described them in the future tense now describe them in the present: the white-label right on paid subscriptions, what paid tiers buy, and the historical archive being a paid product. No term changed meaning and nothing new was promised; the launch simply happened. The archive paragraph now points at the pricing page rather than inviting an email, with the email kept for anything the published plans do not fit. No change to the free tier, to refunds, to the SLA, or to what counts as “used”.
• 27 September 2026 — the Availability SLA now covers the live websocket service as well as the /v1 REST API. This widens what is covered: nothing has been taken away. The 20 September entry below narrowed it to REST only for one reason — nothing on the status page measured the websocket service, and it said that when a probe was added this section would widen again and the changelog would say so. The probe was added the same day, and this is the changelog saying so. The two services are now assessed as a single figure, and a minute counts as down if either is down, which is the stricter of the available readings and the one already published. The first assessed month is still October 2026, so no month has ever been judged under the narrower wording. No change to the committed percentages, to the credit bands, to the claim window, or to the free tier. In the same pass, three changes in Continuity. One promise there is narrowed, and it is the archive one. It said the historical archive would be released openly if the service wound down; it now says a home will be found for it. The reason is that the first thing a buyer's agreement might forbid is publication, so the stronger wording was a promise we could have been forced to break in exactly the situation it was written for — a sale, or a wind-down. A weaker promise that will be kept is worth more than a stronger one that might not be, and this is corrected before anyone has paid anything in reliance on it. Second, and in the other direction, a commitment is added: if the service wound down while you were subscribed, the unused part of what you paid comes back to you. That is the Refunds rule applied to the one case where there is nothing left to put right, and it could not mean anything until subscriptions existed. Third, a correction of fact: parksapi was called “the collector library” and is the data fetching library — the collector itself is not public, and the two should not be conflated.
• 20 September 2026 — the Availability SLA now covers the /v1 REST API only, and says so. It previously named the websocket service as well, which nothing measures: the status page probes HTTP, and a commitment we do not publish a figure for is not one you could hold us to. The pricing page and the plan catalogue already said "REST API", so this makes the three agree rather than taking anything away — and it is corrected before the first assessed month, which is October 2026, so no month has ever been judged on the wider wording. When a websocket probe is added to the status page, this section widens again and this changelog will say so. A websocket outage is still an outage: the Refunds section still applies to a prolonged one that stops you using what you paid for. In the same pass, the month the figure is measured over is now stated as a UTC calendar month rather than an unnamed one, and the figure is assessed exactly as published, to four significant figures. Two corrections in “Rate limits & fair use” the same day: requests are counted against your account when a key or a session is presented, not per API key — several keys on one account share one allowance, which is what the limiter has always done — and the pointer to where the figures live now names the pricing page, which is generated from the catalogue the API enforces, rather than saying they would be published “if and when” plans exist. No change to the credit rates, to the claim window, to refunds, or to the free tier.
• 8 September 2026 — added the Availability SLA section: 99.5% monthly availability on Business and 99.9% on Enterprise, covering the /v1 REST API and the websocket service, measured on the figures published on the status page, with capped service credits as the remedy and a 30-day window to claim one; on an annual subscription a month's fee means one twelfth of the annual fee. The free tier and Pro carry no SLA and no credits, as before. It is a promise about our service responding and not about the park data, which still carries no guarantee of completeness, freshness, or accuracy on any tier. The first assessed month for Business is October 2026. In the same pass, the redistribution rule in "What is not allowed" now states the Enterprise exception the price list already advertised: redistribution remains unavailable on every self-serve plan — the free tier, Pro, Business — and can be granted only by a named, revocable, written exception under an Enterprise agreement, which no plan confers by default. No change to the free tier, to refunds, or to what counts as "used".
• 8 September 2026 — remedies and liability, tightened in both directions at once. Service credits are now your sole and exclusive remedy for missed availability, and our total liability for all claims together is capped at the fees paid for the Service in the twelve months before the claim, however they were collected — the fees you paid through Paddle count — and nil if nothing has been paid, which is the position on the free tier. Where a credit cannot be applied because your subscription has ended, we pay it out rather than let it lapse. Against that: the refund promised in Refunds when a prolonged outage stops you using what you paid for is expressly carved out of that exclusivity, and is neither withdrawn nor narrowed. The one change to it is that you take the refund or the credit for the same outage, not both — a credit already given counts towards the refund and we pay the difference, so you are never worse off than the larger of the two. Separately, the Availability SLA is now an express exception to the "no warranty of any kind" disclaimer, for availability only: the accuracy, completeness and freshness of the park data stay disclaimed on every tier. Your statutory rights are untouched: a term cannot lawfully exclude what the law says it cannot, and the paragraph that follows the cap says exactly that.
• 7 September 2026 — Paid subscriptions now says that access starts as soon as a subscription does, and what that costs you if you change your mind. Refunds now separates the two kinds of paid feature instead of treating them alike: what you download, such as history beyond the free window, is delivered when you retrieve it and the 14-day right stops covering it, while continuing access, such as the firehose, is supplied across the period you paid for, so using it does not end that right — ask inside the window and the part of the period you have not had comes back. That gives you more than this section did before, not less: a connection alone is no longer a reason to refuse. No change to what counts as "used", to renewals, to our-fault refunds, or to the free tier.
• 7 September 2026 — the API key form now asks you to tick a box confirming you accept these terms, and we keep a record of which dated version you accepted and when. No change to any term.
• 7 September 2026 — added the Paid subscriptions section (Paddle as merchant of record, automatic renewal and cancellation, the price lock) and the Refunds section. Refunds are measured on the account, not on individual API keys: paid features reached while signed in on this website count as use in exactly the same way as requests made with a key, and a discretionary refund is decided on what the account did by either route. The earlier promise of separate commercial terms for self-serve plans is replaced by those sections; Enterprise remains negotiated. No change to the free tier.
• 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.