Why ParkDay reads your screenshots: the closed door of the My Disney Experience API

One of the first questions thoughtful users ask after signing up for ParkDay is some version of "wait, how does this work?" The skeptical version is sharper: "you can't possibly have access to my Disney reservations — Disney would never let you do that." Both are right. ParkDay does not connect to Disney. There is no API key, no partnership, no developer portal we logged into. We built around the absence of those things. The result, perhaps counterintuitively, is more durable and more user-respecting than a hypothetical API integration would have been.

What "no API" actually means

Disney has no public, documented, developer-accessible API for My Disney Experience. They have private internal APIs that the official MDE app and disneyworld.disney.go.com talk to, and they have partnership-level integrations with a handful of approved companies (large travel agencies, certain cruise lines, hotel partners). Outside of those partnerships, there is no developer program you can sign up for. There is no rate-limited public endpoint. There is no OAuth flow that lets a user grant a third-party app read access to their reservations the way you can grant Spotify access to your Last.fm history.

This is not an oversight. It's a deliberate strategic posture. Disney has spent more than a decade investing in MagicBand, MDE, Genie+, Lightning Lane Multi Pass, and the surrounding digital infrastructure as a competitive moat. The data inside MDE — what you booked, when, where you ate, how often you ride Tower of Terror — is one of Disney's most valuable consumer datasets. Opening it up to third parties would commoditize the experience layer Disney has built. It's not happening, and there's no commercial pressure that's going to change Disney's mind.

So if you want to build a tool that helps Disney guests plan, you don't have the option of "we'll just call the API." You have to find another path.

The two paths that aren't the answer

Scraping

The most obvious path is the wrong one. You could scrape disneyworld.disney.go.com or reverse-engineer the private MDE API the official app uses. Some third-party tools have done this over the years. From an engineering standpoint, this works for short stretches: capture the auth flow, replay it programmatically, fetch reservation data, parse it. From a product standpoint, it has three structural problems that compound over time.

First, it requires the user to hand over their Disney account password — or, worse, accept that the third party will store and use it. There is no way to do read-only scraping without full account credentials, because Disney doesn't expose any narrower scope. Asking users to type their Disney password into an unrelated company's website is a meaningful trust ask, and a justified one for users to refuse.

Second, it's terms-of-service hostile. Disney's user agreement explicitly prohibits automated access to MDE outside of their official channels. You don't have to be a lawyer to read the terms and conclude that scraping is a one-cease-and-desist-letter business. The history of consumer-facing scraping tools that ran into legal walls is long and sobering — anyone who lived through the LinkedIn vs. hiQ Labs cycle, or watched the various flight-aggregator lawsuits, knows what happens when a platform decides it's done tolerating you.

Third — and this is the most quietly damaging — it's fragile in a way users feel. Disney rotates their internal endpoints, ships A/B tests that change response shapes, and adds friction (CAPTCHA, device fingerprinting, rate-limit tightening) every few months. A scraper that worked great in March stops working in May. Users don't see "the third-party tool's scraper broke" — they see "this tool I paid for stopped updating my plan, what's the point of it?" The product erodes from underneath.

For all three reasons combined, scraping was a non-starter for ParkDay. Any planning tool built that way is, in our view, working on borrowed time.

Manual entry

The other obvious path is just to ask the user to type everything in. This is what the early generation of Disney planning sites did, and many still do — you sign up, you have a calendar grid, and you painstakingly enter every dining reservation you booked, every Lightning Lane you holdered, every park day. Then when Disney emails you that your dining time changed, you go back and edit your spreadsheet.

This works in the sense that you can build a real product around it, and many have. But it loses the entire value proposition of automation. The whole reason a planning tool is interesting is that it relieves you of bookkeeping. If you're still typing every reservation by hand and updating it every time something changes, you've just replaced one tedious system with another one that has worse keyboard ergonomics. And the tool inevitably falls out of sync — not because the tool is broken, but because humans don't reliably re-enter data when something changes for the third time on a Tuesday.

The two paths Disney does open

So scraping is fragile and credential-heavy, manual entry abandons the value prop. What's left? Two surfaces, both of them user-mediated, both of them consented, both of them durable in a way scraping isn't:

Screenshots

Every reservation a user makes through MDE is visible to that user inside MDE, on their own phone, in plain pixels. Five years ago this was a dead end — turning a screenshot into structured data was an OCR project that worked sometimes and produced nonsense the rest of the time. The vision capabilities of modern foundation models have changed that. A frontier-class vision model can read an MDE screenshot the way a human reads it: this card is a dining reservation at Sci-Fi Dine-In at 6:00 PM for four guests; this card is a Lightning Lane Multi Pass for Slinky Dog Dash with a 1:15 PM return window; this card is the Beach Club Resort hotel check-in for April 25.

The user owns the data. The user takes the screenshot. The user uploads it. There is no third-party access to anything the user didn't explicitly choose to share. There is no Disney account password involved. The pipeline has zero dependence on Disney's infrastructure being any particular shape — if MDE's UI changes next month, the vision model adapts because it reads what's on the screen, not specific HTML element IDs.

Screenshots also give you something scraping never could: the exact view the user sees. If MDE shows a reservation with a particular set of details the user finds meaningful, the screenshot has those details. There's no risk of "the API returned the field but our parser doesn't know about it" — the parser is a vision model staring at the same image you'd stare at.

Email

The second user-mediated surface is even more reliable: Disney's confirmation emails. Every time you book a dining reservation, modify it, cancel it, buy a Lightning Lane Single Pass, change a hotel reservation, or update a park reservation, Disney sends you an email. This has been true for as long as MDE has existed. Disney sends these emails because their Legal team requires written confirmation of consumer transactions — even if Disney rebuilt MDE from scratch tomorrow, the emails would still go out, because they're a regulatory artifact, not a UI artifact.

If you can read those emails, you have a structured event stream of every meaningful change to a guest's plan. The user doesn't have to do anything except set up a one-time forwarding rule in their email account: "any message from disneydestinations.com, mydisneyexperience.com, or disneyreservations.com gets forwarded to my unique ParkDay address." From then on, every confirmation Disney sends lands at our backend within seconds.

This is profoundly user-respectful in ways scraping cannot be. We never see anything other than the Disney confirmation messages the user explicitly chose to forward. We have no access to the rest of their inbox, no access to their account password, no permission to read anything else. The forwarding rule is set up by the user, in their own email account, and they can disable it at any time without telling us — the firehose just stops.

One important caveat: not every Disney action generates an email. Lightning Lane Multi Pass bookings — the standard tap-to-book LLs you do throughout the day — don't trigger emails. Lightning Lane Single Pass / Individual Lightning Lane purchases (Rise of the Resistance, TRON, Cosmic Rewind) do, because they involve a real-money transaction. Dining, hotel, park reservations, and special experiences (Bibbidi Bobbidi, Droid Depot, Savi's Workshop) all email. So the email pipeline covers most changes automatically, and the screenshot import covers the remaining LLMP gap with a 30-second re-upload.

The architecture this all leads to

Once you accept that the only durable inputs are screenshots and forwarded emails, the rest of the architecture writes itself:

• Onboarding uses a screenshot to bootstrap the trip. One scrolling screenshot of the user's "My Plans" view in MDE imports every confirmed reservation in seconds. Day-tab labels at the top of MDE tell the parser which date each card belongs to. The result is a populated plan within thirty seconds of upload, with zero manual entry.
• Steady-state sync uses email forwarding for everything Disney emails about, and lightweight screenshot re-uploads for LLMP changes. The user only thinks about their plan when something changed — and the affected card on their plan has already been updated by the time they look.
• The AI assistant understands the full schedule (because we have the full schedule, in structured form) and can take requests like "add a snack break at Blizzard Beach at 1:30 on Thursday" and place a card on the right day with appropriate context. This is only possible because the underlying data is clean and complete. It would not be possible from a partial scrape.
• Notifications tell the user when something arrived. Push to all their devices, a row in the Notifications panel, full change history.

None of this requires a Disney API. None of it requires the user's Disney password. None of it depends on Disney not changing anything about MDE. The pipeline is robust in proportion to how robust user actions and email infrastructure are, which is to say: very.

What we miss

It would be dishonest to pretend the screenshot + email architecture is a perfect substitute for an imaginary Disney API. There are real things we don't see, and being clear about them is part of the contract:

• LLMP changes between screenshot uploads. If you book a Lightning Lane Multi Pass at 9:30 AM on a Tuesday and don't re-upload until Thursday, your plan won't show the LL you booked Tuesday until Thursday's upload. This is a real lag.
• Live wait times as a primary feature. ParkDay does pull live wait-time and ride-status data from independent third-party feeds (ThemeParks.wiki, queue-times.com) and uses it under the hood — for example, the AI suggester won't recommend a ride that's currently down for refurbishment. But we don't (yet) surface minute-by-minute standby waits as a primary in-app dashboard. MDE's own Tip Board is still the canonical place to glance at the moment-by-moment numbers.
• Anything not in your plan. If you want suggestions for a fifth park day, we can help with that based on what you've told us. If you want a recommendation that depends on knowing every other guest's choices the way Disney's recommendation engine could in theory know, we can't do that.

For everything else — the structure of your trip, the cards on each day, the rhythm of arrival and departure, the dining and rides and hotel — we have what you have, because you gave it to us.

The summary, for the skeptical user

Disney closed the door on third-party developer access years ago and has never reopened it. Tools that route around this by scraping work for a while and then break, take your password as the price of entry, and exist in tension with Disney's ToS. ParkDay routes around it differently: by treating the user's own screenshots and email confirmations as the source of truth. Both are things you already own and already see. We just turn them into structured data fast enough for the result to feel like magic.

If a Disney API ever opens up, we'll integrate. Until then — and probably forever, judging by the past decade — the architecture below is the right one.