Overview
The Attractions.io integration sends live data from Mobaro RideOps to your Attractions.io guest app. When an Operator posts a queue time in RideOps, or a ride opens or closes, Mobaro updates that ride's queue in Attractions.io, so guests see current wait times without anyone updating two systems.
The integration is one-way: Mobaro sends, Attractions.io receives. Nothing comes back from Attractions.io into Mobaro.
At a glance |
|
Who can do this | Super Users, or a Role with Organization › Administrate. Mapping a Location's Queue Id needs Locations › Modify. |
Where | Configuration › Integrations › Attractions.io, then Locations › a Location › RideOps Settings › Queues |
Works on | Backend (web) to set up. Data is sent when Operators work in RideOps. |
Availability | All organizations with RideOps and an Attractions.io guest app |
💡 Why this matters: Guests plan their day around wait times. When RideOps is already where Operators post queue times and open or close the ride, feeding it straight to the guest app keeps the app accurate without extra work at the ride.
What Mobaro sends
For each mapped Location, Mobaro sends Attractions.io three values: the wait time, whether the ride is operational (yes or no), and, with queue updates, your Queue Time Message. There's no separate Downtime state.
When this happens | Mobaro sends |
An Operator posts a queue time in RideOps | The new wait time, operational = yes if the Location is open (no if it's closed), and the Queue Time Message if you set one |
The Location opens | Operational = yes, with the wait time reset to 0 |
The Location closes, including when a Downtime starts on an open ride | Operational = no, with the wait time reset to 0 |
⚠️ Heads-up: Opening or closing a ride resets the wait time in Attractions.io to 0 until an Operator posts the next queue time in RideOps. A Downtime is sent exactly like a closure, so the guest app can't tell a breakdown from a planned closure. How "not operational" is labelled for guests is set in Attractions.io, not in Mobaro.
Only queue times posted from the RideOps queue widget are sent. Queue entries added in the Backend, or received from other integrations or the Mobaro API, aren't sent to Attractions.io. Opening and closing is sent wherever it happens — RideOps, the Backend or the app. See Managing queues and dispatches in RideOps.
Before you start
An Attractions.io guest app for your park.
An API Key from Attractions.io. Mobaro doesn't generate it.
A Queue Id from Attractions.io for each ride you want to share.
RideOps turned on for those Locations. See Setting up RideOps.
Set up the integration
1. Open Integrations
In the Backend, go to Configuration and open the Integrations tab. Each partner card shows Enabled or Not enabled.
2. Open Attractions.io
Click the Attractions.io card.
3. Enter your settings
Tick Enable integration to Attractions.io, then fill in:
API Key (required) — the key Attractions.io gave you.
Queue Time Message (optional) — shown in the guest app with each queue time update. Leave it empty if Mobaro shouldn't update the status message.
Click Save. The card now shows Enabled.
4. Map each ride's Queue Id
Go to Locations, open the ride and its RideOps Settings. In the Queues section, enter the Attractions.io Queue Id in Attractions.io Queue Id and save the Location. The field only appears once the organization has an API key saved. Repeat for every ride you want in the guest app.
Locations without a Queue Id, or without RideOps turned on, aren't sent.
Check that it works
In RideOps on a mapped ride, post a new queue time and check that the guest app shows it.
Close and reopen the ride, and check that the guest app shows it as not operational and then operational again. The wait time shows 0 until the next queue time is posted.
Mobaro doesn't show delivery errors in the Backend. If updates don't arrive, check the API Key and the ride's Attractions.io Queue Id, then contact Mobaro Support, who can see failed requests.
Turn the integration off
To stop sending for one ride, clear its Attractions.io Queue Id. To stop for the whole organization, untick Enable integration to Attractions.io and click Save; this removes the saved API Key and Queue Time Message, so you'll need to enter them again to turn the integration back on.
Best practices
Start with one ride during operating hours and check the guest app before mapping the rest.
Ask Operators to post a queue time right after opening a ride, as opening resets the wait time to 0.
Keep a list of Queue Ids per ride, so a Location that's re-created or renamed can be mapped again quickly.
Frequently asked questions
We closed a ride but the app doesn't show it as closed. Why?
Mobaro sends operational = no with a wait time of 0 when a Location closes or a Downtime starts. How the guest app shows a non-operational ride is configured in Attractions.io, so check the display settings with your Attractions.io contact.
Where do the API key and Queue Ids come from?
From Attractions.io. They create the queue for each ride and give you its Queue Id and your API key. Mobaro doesn't generate either.
Can I update the wait time from the Backend instead of RideOps?
No. Only queue times posted in RideOps are sent to Attractions.io. Queue entries added in the Backend are stored in Mobaro but not sent.
Does Attractions.io show Downtime separately from Closed?
No. Mobaro sends a Downtime on an open ride the same way as a closure: operational = no, wait time 0.
Is the integration two-way?
No. Mobaro only sends data. Nothing from Attractions.io is received or stored in Mobaro.