Skip to main content

Understanding IDs in Mobaro

Learn what IDs are in Mobaro, where to find them, and how to use them when working with the API and automations.

Logan Bowlby avatar
Written by Logan Bowlby
Updated this week

Overview

Every object in Mobaro — such as users, locations, assets, assignments, and results — has a unique ID. These IDs allow the API (and integrations like Power Automate, internal scripts, or analytics tools) to reference the correct item with absolute precision.

If you’re using the Mobaro API, the most important thing to understand is how to look up, store, and reference these IDs consistently.

What is an ID?

An ID is a system-generated value that uniquely identifies a record inside Mobaro.

Examples:

Record Type

Example ID

Purpose

User

user/185465-B

Who performed the action

Location

location/78264-C

Where the action happened

Asset

asset/7556-A

Which equipment or ride is referenced

Checklist Result

result/72564-A

The specific completed checklist

Note: IDs are GUIDs. The API always uses the system ID — even if a human-friendly label exists.

Where to find IDs in Mobaro

From the Mobaro backend (UI)

You can sometimes view IDs directly in the browser:

  1. Navigate to the item (e.g., a checklist)

  2. Look at the URL

  3. The final portion of the URL is the item’s ID

Example URL:

https://app.mobaro.com/#/checklist/editor/102170-A

ID = checklist/102170-A

Tip: This works for checklists only currently.

Using the API (recommended for system integrations)

Call the corresponding endpoint and look for the id field.

Example — list users:

curl "https://app.mobaro.com/api/customers/users" \
  --header "X-Api-Key: YOUR_SECRET_TOKEN"

Example — list locations:

curl "https://app.mobaro.com/api/customers/locations" \
  --header "X-Api-Key: YOUR_SECRET_TOKEN"

Use the IDs from the response when referencing related objects in scripts and automation.

How IDs relate to each other

Some objects reference other object IDs.


For example, a result references:

Field

Meaning

checklistId

Which checklist was used

locationId

Where it was performed

assetId (optional)

Which asset was inspected

userId

Who performed it

This relationship structure makes Mobaro flexible and scalable.

Matching external data to Mobaro IDs

If your HR, CMMS, scheduling, or access-control systems already maintain their own identifiers, you don’t need to replace them. Instead, you can map or store those identifiers in Mobaro so your integrations can reference records consistently.

Mobaro supports External IDs on:

  • Users

  • Locations

  • User groups

  • Location groups

This allows your systems to reference the same item without depending on Mobaro’s internal GUID.

System Type

Common External Identifier

Integration Strategy

HR / Identity System

Employee ID

Store the Employee ID in the user’s External ID field. When syncing, match on external ID → then retrieve the Mobaro user ID.

CMMS / Maintenance System

Asset Tag / Equipment Code

Store the asset tag as an Asset Property or External ID on the Asset. Use this as your lookup key when creating downtime, assignments, or inspections.

Scheduling / Rostering System

Location Code / Area Code

Store the scheduling system’s location code in the Location External ID field to match users to work areas automatically.

Training / Certification System

Training Record ID

Store certification identifiers in the user’s Competencies/Certifications metadata or External ID field depending on scope.

Why use External IDs?

Using External IDs allows all connected systems to speak a shared language, while Mobaro continues to manage its internal references safely and consistently.

Best practice:

  • Use External ID fields to maintain links to other systems

  • Use email as the primary match key for users when first connecting systems

  • Use Mobaro internal IDs only inside API requests and automation logic

This prevents common issues like mismatching records or accidentally creating duplicate users or assets.

Avoiding duplicates

When syncing users, assets, or locations:

  1. Search for an existing record by a known unique field (e.g., email or asset tag)

  2. If found → update

  3. If not found → create

This ensures clean data and avoids multiple IDs referring to the same person/place.

Best practices

  • Store IDs in your automation scripts or sync tables.

  • Use email addresses for matching people across systems.

  • Use location groups instead of manually assigning multiple locations.

  • Never hard-code IDs without documenting them.

If you rename something in Mobaro, the ID does not change, so integrations remain stable.

Did this answer your question?