Overview

The Mobaro API lets you create and update Locations at scale: to stand up a new environment, restructure an existing one, or keep Mobaro in sync with another system such as a CMMS or ERP. This article covers the Location endpoints, the order to create things in, common pitfalls and a worked example.

Locations themselves aren't nested. To build a structure such as park › area › ride, you use Location Groups, which can have a parent group, and add each Location to the groups it belongs in. If you'd rather not script an import, Mobaro can import Locations from an Excel workbook for you; see Import from Excel below.

At a glance
Who can do this	An API key without Read-only; it acts as a Super User. Keys are created by Users with Organization › Administrate. Excel imports are run by Mobaro.
Where	`https://app.mobaro.com/api/customers/locations`; keys in Configuration › API › API Keys
Works on	Public API
Availability	API access is enabled per organization by Mobaro — ask your CSM

💡 Why this matters: Schedules, Assignments, Assets and reporting all hang off Locations. An API-driven sync keeps Mobaro matching your real site list, and a one-off bulk import gets a new environment working in hours instead of weeks.

The Location endpoints

The Location endpoints use HTTPS and JSON, with your key in the X-Api-Key header; see Getting started with the Mobaro API. For exact fields, types and validation, see the Mobaro API documentation.

Operation	Endpoint	Notes
List	GET `/api/customers/locations`	Paged. Filter by Location Group and created or updated dates. See Mobaro API parameter reference.
Get one	GET `/api/customers/locations/{id}`	Accepts the Mobaro ID or your External ID.
Create	POST `/api/customers/locations`	One Location per request. Returns the new ID.
Update	PUT `/api/customers/locations/{id}`	Changes only the fields you send. A list you send replaces the whole list.
Update relations (Beta)	POST `/api/customers/locations/{id}/relations`	Adds or removes Users, User Groups and Location Groups.
Delete	DELETE `/api/customers/locations/{id}`	One Location per request. Can't be undone.

The create request accepts name (required), email, language, externalId, scannerCode, timeZone, address, operationalLogging, rideOps and rideOpsSettings, openingHoursCalendars, and the ID lists users, userGroups, properties and locationGroups. There's no parent, code or description field.

⚠️ Heads-up: Fields the API doesn't recognise are ignored without an error. A payload with parent, code or description still creates the Location, just without that data, so check the result rather than relying on the response.

Import in the right order

1. Prepare your source data

Give each Location one row with at least a Name and an External ID: your stable identifier from the source system, which lets you find the Location again on the next run. Add the time zone, email and the Location Groups it belongs to. Location Properties must already exist in Mobaro; you pass their IDs. See Creating and assigning Location Properties.

2. Create the Location Groups

Create groups top-down with POST /api/customers/locationgroups, passing parent for each child group, so every parent exists before its children. Keep a map of your identifiers to the Mobaro IDs that come back. Location Group writes are limited to one request every 15 seconds per API key, so pace this step. See How to create Location Groups.

3. Create the Locations

POST each Location with the IDs of its groups in locationGroups. Before each POST, look the Location up by External ID with GET /api/customers/locations/{externalId}; if it exists, use PUT instead, so re-running the script doesn't create duplicates.

4. Check the result

List the Locations, filtered by Location Group, and compare them with your source data. Then open Locations in the Backend and spot-check a few, including their groups and time zones.

Worked example

This request creates a Location in an existing Location Group:

curl "https://app.mobaro.com/api/customers/locations" \
  --request POST \
  --header "Content-Type: application/json" \
  --header "X-Api-Key: YOUR_API_KEY" \
  --data '{
    "name": "Galaxy Coaster",
    "externalId": "GC-001",
    "timeZone": "America/New_York",
    "operationalLogging": true,
    "locationGroups": ["locationgroups/123-A"]
  }'

The response contains the new Location's ID, for example locations/456-A. IDs include their prefix; see Understanding IDs in Mobaro.

Common pitfalls

No uniqueness checks. Mobaro doesn't enforce unique names or External IDs, so re-running a POST creates a duplicate. Always look up by External ID first.
PUT replaces lists. Sending locationGroups, users or userGroups in a PUT replaces the whole list. To add or remove single entries, use the relations endpoint.
Rate limits. Each key can make up to 10 requests per second, and Location Group writes one every 15 seconds. Over the limit you get 429; wait and retry. See Handling errors, rate limits, and retry logic.
Time zones. A wrong time zone skews Downtime totals and Schedule windows. Set it on import. See How opening hours affect downtime tracking.
RideOps. rideOps only takes effect with operationalLogging set to true, and needs valid rideOpsSettings.

Delete Locations

DELETE removes one Location per request. It also takes the Location out of Schedules, future slots, Location Groups and notification rules.

🛑 Critical: Deleting a Location can't be undone. Assets at the Location aren't moved or deleted, so move them to another Location first. Test deletion scripts on a few Locations, and log every ID you delete.

Import from Excel

Mobaro can import Locations from an Excel workbook for you, typically during onboarding. The import is run by Mobaro, not from your Backend. It reads the first sheet, with the columns Name, Email, Externalid and OperationalLogging; the Name and Email column headers must both be present, and it stops at the first row without a name. It creates Locations only, without Location Groups or other settings. Ask your CSM or email [email protected].

Best practices

Build for re-runs. Look up by External ID, then POST or PUT, so the import works as a sync.
Test with a small set first, including the deepest group structure and any Location Properties.
Use a dry-run mode that logs what would be sent, to catch missing groups and time zone mistakes.
Import Assets afterwards. Assets hang off Locations, so create Locations first; see Bulk imports and API access for Assets.
Use a key made for the job, and delete it when a one-off import is finished. See Creating and managing API keys and Understanding API access scopes and limitations.

Frequently asked questions

How do I find the ID of a Location?

Call GET /api/customers/locations: each item has its Mobaro ID, such as locations/456-A, and your External ID. You can also get a single Location by its External ID. See Understanding IDs in Mobaro.

Can I import Locations as sub-locations under a parent?

No. Locations have no parent. Create Location Groups with a parent group for the structure, then add each Location to its groups with locationGroups. See How to create Location Groups.

Can we delete Locations after creating them?

Yes, one at a time with DELETE /api/customers/locations/{id}, or on the Locations page. It can't be undone, and Assets at the Location aren't moved, so move them first. See How to create Locations.

How can I export my list of Locations?

Page through GET /api/customers/locations with Limit and Offset until you've read total items. See Mobaro API parameter reference.

Can I upload a spreadsheet of Locations myself?

No. There's no self-serve spreadsheet import. Use the API, or ask your CSM to have Mobaro import an Excel workbook with Name, Email, Externalid and OperationalLogging columns.

What's the difference between a Location and a Location Group?

A Location is a place where work happens, such as a ride. A Location Group collects Locations, can sit inside another group, and gives its members access to them. See Overview of Locations in Mobaro.

Importing Locations via the Mobaro API (and Excel)