The Attractions.io integration connects Mobaro RideOps to your Attractions.io guest app so that live operational data captured by your ride operators flows straight into the guest-facing experience — no manual updates, no separate dashboards. This article explains what data Mobaro sends, how it maps to Attractions.io, and how to set the integration up.
Why this matters: Guests increasingly plan their day around live queue times and ride availability. When RideOps is already the source of truth your operators use, feeding that data directly to Attractions.io keeps the guest app accurate in real time without asking operators to update two systems.
What's covered:
What data Mobaro sends
The integration is one-directional: Mobaro is the source, and Attractions.io consumes the data. Nothing flows back from Attractions.io into Mobaro.
Mobaro sends two pieces of live data per Location:
Queue time — the current wait time as set or calculated in RideOps.
Location operational status — whether the ride is open, closed, or in downtime.
Note: Because the flow is one-directional, RideOps remains the single source of truth. Any change made in RideOps — an operator updating the queue time, opening or closing the ride, or logging downtime — propagates to Attractions.io. Changes cannot be pushed the other way.
How operational status maps to Attractions.io
Mobaro's three operational states are mapped to the equivalent state in the Attractions.io guest app so the status shown to guests reflects what your operators see in RideOps.
Mobaro RideOps status | What it means | Attractions.io equivalent |
Open | The ride is operating and admitting guests. Queue time is published alongside this state. | Shown to guests as operating / open, with the live wait time. |
Closed | The ride is not operating as a planned or scheduled closure (for example, outside operating hours or a seasonal closure). | Shown to guests as closed. |
Downtime | The ride is unexpectedly unavailable (an unplanned stoppage or fault) rather than a scheduled closure. | Shown to guests as temporarily unavailable / down. |
Heads-up: Closed (a planned non-operational state) and Downtime (an unplanned stoppage) are sent as distinct states so the guest app can communicate the difference. Confirm with your Attractions.io contact how each state is labelled in your specific guest app configuration, and how queue time is displayed while a ride is in downtime.
Before you start
You'll need the following in place before configuring the integration:
An active Attractions.io account with the integration enabled on their side.
The integration credentials provided by Attractions.io (for example, an API key or endpoint details).
RideOps configured for the Locations whose queue times and status you want to share.
Users must be Super Users or have a Role with permission to manage Configuration to set up this integration.
Setting up the integration
1. Open the integrations configuration
In the Mobaro Backend, go to Configuration and open the Integrations tab.
2. Select the Attractions.io integration
Locate Attractions.io in the list of available integrations and open it.
3. Enter the Attractions.io credentials
Enter the credentials provided by Attractions.io (such as the API key or endpoint). These come from Attractions.io — Mobaro does not generate them.
4. Map the Locations' Queue ID to share
For each Location that should be mapped to the Attractions.io integration, map each Attractions.io-provided Queue ID to the RideOps settings of the applicable Location.
5. Save and enable
Save the configuration and enable the integration. Once active, Mobaro begins sending queue time and operational status for the mapped Locations.
Best practice: Enable the integration during operating hours with a single test Location first, so you can confirm the live data appears correctly in the Attractions.io guest app before mapping your full ride lineup.
Verifying the integration
After enabling, confirm the data is flowing correctly:
In RideOps, set or change a queue time for a mapped Location and confirm the new value appears in the Attractions.io guest app within the expected sync window.
Change the Location's operational status (open, closed, or log downtime) in RideOps and confirm the guest app reflects the corresponding state.
If values don't appear, re-check the credentials and that the Location is mapped, then contact Mobaro support.
Note: There may be a short delay between a change in RideOps and it appearing in the guest app, depending on the sync interval. A small lag is expected; data that never appears indicates a configuration issue.
Frequently asked questions
Q: Is the integration two-way?
A: No. It is one-directional. Mobaro sends queue time and operational status to Attractions.io. Nothing is sent from Attractions.io back into Mobaro, and RideOps remains the source of truth.
Q: What exactly does Mobaro send?
A: Two things per mapped Location — the current queue time, and the operational status (open, closed, or downtime).
Q: What's the difference between Closed and Downtime in the guest app?
A: Closed is a planned or scheduled non-operational state; Downtime is an unplanned stoppage. Mobaro sends them as distinct states so the guest app can communicate the difference to guests. Exact labelling depends on your Attractions.io configuration.
Q: What happens to the displayed queue time when a ride goes into downtime?
A: The operational status changes to reflect the downtime. How the queue time itself is displayed during downtime depends on the Attractions.io guest app configuration — confirm this behaviour with your Attractions.io contact.
Q: Do I have to share every ride?
A: No. Only the Locations you map are included in the feed. You can start with a subset and expand later.
Q: Where do the Attractions.io credentials come from?
A: From Attractions.io. Mobaro does not generate them — request them from your Attractions.io contact before setting up the integration.