How ParkDay works: turning your reservations into a living touring plan
A walkthrough of the three pieces that make ParkDay tick โ the screenshot import, the email pipeline, and the AI assistant โ plus what we do and don't see along the way. If you've ever wanted to understand a tool before signing up for it, this is for you.
ParkDay is a deliberately small product doing a deliberately well-defined job: turn your Walt Disney World reservations into a living, day-by-day touring plan that updates itself as Disney makes changes. It's not a recommendation engine, it's not a forum, it's not trying to be MDE plus a thousand features. It does three things, and it tries to do them really well. This is what those three things are, in plain English.
The 30-second tour
- You upload a scrolling screenshot of your "My Plans" view from the My Disney Experience app. ParkDay reads every reservation in the image and builds out your trip.
- You set up a one-time email forwarding rule for Disney confirmation messages. From then on, every change Disney emails you about lands as a real-time update on your plan.
- You can talk to ParkDay in plain English โ "add a snack break at Blizzard Beach at 1:30 on Thursday" โ and it adds the right card to the right day with appropriate context.
That's the whole product. Everything else (notifications, walk times, the height guide, prep checklists, the AI Pro Moves) is in service of those three pillars.
Pillar 1 โ Screenshot import
The first thing you do after creating an account is upload one scrolling screenshot per day of your trip. Within seconds, your plan is populated.
What happens when you upload
Each screenshot is sent to a vision-capable language model with a prompt that knows the visual language of MDE. The model reads each card it sees on your "My Plans" screen and classifies it: is this a dining reservation? A Lightning Lane Multi Pass? A Lightning Lane Single Pass / Individual Lightning Lane? A park reservation? A hotel check-in? A special experience like Bibbidi Bobbidi Boutique? The day-tab strip at the top of MDE ("Mon 4/28") tells the model which date the cards belong to.
The model emits a list of structured commands โ "add this dining reservation to April 28 at 6:00 PM" โ and the backend applies them to your plan. Each event gets a card on the right day at the right time, with the location, the party size, the return window (for Lightning Lanes), and so on.
What we deliberately skip
MDE shows two completely different kinds of cards on the My Plans screen: confirmed reservations and "Top Pick" / "Recommended" suggestions. These can sit right next to each other and look superficially similar. The vision pipeline is tuned to be conservative โ if a card doesn't have a clear booking indicator (a "Booked" badge, a confirmation number, or a return-time window), we leave it out. Importing a phantom suggestion and having it conflict with a real reservation later is a much worse user experience than asking you to add one card by hand.
Re-uploads: additive vs. replace
Plans change. When you upload screenshots a second or third time โ say, after booking a new dining reservation โ ParkDay asks how you want to merge them: "Add to my existing plan" preserves everything that's already there and only adds new items, with a 30-minute dedup window so the same reservation can't accidentally land twice. "Replace these days" clears AI suggestions and unlocked manual additions on the affected days but keeps real, locked reservations intact, so a partial-day screenshot upload can never accidentally nuke a reservation that wasn't in the picture. Most ongoing uploads are additive; the replace mode is for when you've heavily reworked a day and want a clean slate.
Pillar 2 โ Email forwarding
Screenshots are great for the initial import and for big changes, but you don't want to take a screenshot every time Disney shifts your dining time by fifteen minutes. The email pipeline is what handles the long tail of small changes throughout your trip.
How it's set up
During onboarding, ParkDay gives you a unique forwarding address โ something like [email protected]. You set up a one-time filter in your own email account: any message from disneydestinations.com, mydisneyexperience.com, or disneyreservations.com gets auto-forwarded to that address. The exact UI for setting this up depends on your provider โ Gmail's filters page, Outlook's Inbox Rules, iCloud's mail-rules in System Preferences โ but it's a one-time, two-minute task.
Critically, the forwarding rule lives in your email account. We never have your password. We never see anything except the messages your rule forwards to us. If you decide to disable the rule, the firehose just stops; you don't have to tell us. This was a deliberate trust-architecture choice โ it's covered in detail in the whitepaper on Disney's closed API.
What happens when an email arrives
Every Disney email that hits our forwarding address goes through a two-step pipeline. First, a lightweight classifier checks whether the message is actually a Disney reservation, modification, or cancellation โ there's marketing mail and newsletters that look superficially Disney-related but aren't actionable. If it passes, a second pass extracts the booking details: what was added, modified, or canceled, on what date, at what time, with what name.
The result is a structured update to your plan. The affected card appears, changes, or disappears within seconds of the email landing. A push notification fires to all the devices you've installed ParkDay on. A row appears in the Notifications panel inside the app, so you have a permanent change history you can scroll through later โ useful for catching an update you saw briefly in a notification but don't remember the details of.
What email covers (and what it doesn't)
Email auto-sync covers the changes Disney actually emails about: dining reservations, Lightning Lane Single Pass / Individual Lightning Lane purchases, hotel check-ins and modifications, park reservations, special experiences (Bibbidi Bobbidi Boutique, Droid Depot, Savi's Workshop). It does not cover Lightning Lane Multi Pass โ Disney doesn't email guests when they book or modify an LLMP. For LLMP changes, you take a quick screenshot of the affected day and use the additive re-upload mode. It's about a 30-second loop.
This split โ email for most things, screenshots for LLMP โ is a feature, not a bug. The email pipeline is wonderfully reliable for what Disney emails about, and the screenshot pipeline is wonderfully reliable for the visual MDE state. Together they cover ~100% of the planning surface.
Pillar 3 โ The AI assistant
The third pillar is the small floating "+" button in the corner of every day view. Tap it, type a request in plain English, hit send. ParkDay updates your plan. Some examples of things it handles well:
- "Add a snack break at Blizzard Beach at 1:30 on Thursday."
- "Add a quiet rest spot near Small World around 2pm."
- "Replace Guardians LL with Test Track LL at 10:30 on Tuesday."
- "Cancel the rest break on April 27 โ we want to push through."
- "Add a churro stop." (no date โ defaults to today if you're in your trip window, otherwise to whichever day tab you're looking at)
How it actually works
Your free-text request is sent to the AI along with a snapshot of your trip context โ the days, the events on each day, the family profile (kids' ages, heights), the resort, the trip date range. The model figures out which day the request applies to, where the family will be at the requested time (which park, which area), and what would actually fit in the available window. It emits a structured command that adds the right kind of card at the right time, with appropriate context (walk time from the prior event, location, a relevant tip).
If the request is a swap or replacement ("change Guardians to Test Track at 10:30"), the assistant emits both a removal and an add. If the request involves a whole park ("we're adding Animal Kingdom to Wednesday"), it updates the park banners for the day. If the request doesn't include a date and we can figure out which date you're focused on, we use that; if we can't, we ask you for one.
What we do to make it not lie
AI assistants are notorious for confidently inventing things. ParkDay's user-facing text passes through two layers of guardrails:
- Prompt-level rules. The system prompt explicitly forbids superlatives ("most popular," "best," "fastest"), forbids claiming specific show times or character schedules unless explicitly confirmed, and instructs the model to use hedged language for crowd or wait predictions.
- A second-pass fact-checker. After the model writes tips for a new card, a lighter-weight second model re-reads them and either passes them through, rewrites them more conservatively, or drops them entirely. Anything that survives this pass and lands in your plan has been verified twice.
This is genuinely cheap to do (the verifier model is a fraction of the cost of the planner model), and it dramatically cuts the rate of confidently-wrong claims. We'd rather a tip be brief and right than long and wrong.
What we don't see
Some of the most reassuring things about ParkDay are the things it deliberately can't access:
- Your Disney account password. We never ask for it, and there's no field where you could enter it even if you wanted to. The screenshot upload doesn't require it. The email forwarding doesn't require it.
- Your inbox beyond Disney. The email pipeline only sees messages your forwarding rule sends to us. We have no read access to anything else in your account.
- Live waits as a primary in-app feature. ParkDay does subscribe to live wait-time and ride-status feeds from independent third-party sources (ThemeParks.wiki, queue-times.com) โ the AI suggester uses them under the hood to avoid suggesting closed rides. We don't (yet) surface minute-by-minute waits as a primary dashboard view in the app; for that, MDE's Tip Board is still your best source. We also don't pull from any Disney API directly.
- Your physical location. ParkDay doesn't ask for or use device location. The day plan is yours to follow on your own time.
- Other guests' plans. No social graph, no "people who booked Cinderella's Royal Table also booked..." โ just your own data.
How updates flow to your phone
Once a change has been applied to your plan โ whether from a screenshot import, an email update, or a "+" button request โ the result fans out to all your installed copies of ParkDay via Web Push notifications. Tap a notification and you land directly on the affected day, with the updated card highlighted. Open the app cold and the plan reflects the change without any pull-to-refresh required. The data layer keeps itself current; you just look at it.
If your trip is multi-device โ you and your spouse both installed ParkDay, plus you also have it on a tablet โ every device sees every change. The Notifications panel reflects which entries have been seen on any device, so you don't get nagged on three screens about the same thing.
The summary
Three pillars: a screenshot import that bootstraps your plan from MDE in thirty seconds, an email pipeline that keeps it in sync as Disney makes changes, and a natural-language assistant that handles the day-of additions and tweaks. Behind them: a vision model reading exactly what you see, a structured command pipeline that writes to your plan, a fact-checker that keeps the AI's text honest, and Web Push for instant updates across devices. None of it depends on Disney exposing data they don't want to expose. All of it depends on you owning your own screenshots and your own emails โ which, as it turns out, is the most durable foundation we could find.
Ready to see it in your trip?
Free trial, no credit card. Upload one screenshot, see the whole pipeline come together in under a minute.
Start free trial โ