Overview
For organizations standing up a new Mobaro environment, syncing Assets from a CMMS, or migrating from a different operations platform, the Mobaro API is the right tool to create and update Assets at scale. This article covers the Asset-specific workflow — where the endpoints live, the dependency order for hierarchical structures, common gotchas, and a worked example. For the full Asset endpoint reference, see the API documentation linked below.
Why this matters: Manually creating hundreds or thousands of Assets through the UI is slow, error-prone, and disconnects your Asset library from whatever upstream system already holds the source-of-truth. An API-driven sync keeps Mobaro accurate as your equipment list evolves, and a one-time bulk import gets you to a working environment in hours instead of weeks.
Required access: Bulk Asset operations need a valid Mobaro API key. The User the key authenticates as must have Locations: Modify in their Role to create or edit Assets. See Creating and Managing API Keys for setup.
Where the endpoint reference lives
The complete, authoritative reference for Asset endpoints — including request bodies, query parameters, and response schemas — is published in the Mobaro API documentation:
This article covers the workflow and the gotchas; refer to the docs for exact field names, types, and validation rules.
The Asset endpoints at a glance
The Asset endpoints follow Mobaro's standard REST conventions (HTTPS + JSON, X-Api-Key header). The shape:
Operation | Method & endpoint | Use it for |
List Assets |
| Pull existing Assets for sync, audit, or snapshot. |
Get a single Asset |
| Fetch one Asset's full detail by ID. |
Create an Asset |
| Bulk import: one POST per Asset. |
Update an Asset |
| Edit a single Asset by ID — for sync from upstream systems. |
Delete an Asset |
| Remove an Asset. |
Note: There is no single "bulk create" endpoint that accepts an array of Assets. Bulk imports are performed by issuing one POST per Asset, typically in a script that iterates over your source data.
A typical bulk import workflow
1. Prepare your source data
Start with a clean, structured source: a CSV, Excel sheet, or export from your existing CMMS. Each row should represent one Asset. At minimum, capture:
Name — required.
Location — the Location ID or External ID this Asset belongs to (must already exist in Mobaro).
Parent Asset — if applicable, the parent Asset's ID or External ID (the parent must be created first).
External ID — your stable identifier from the source system. Strongly recommended for any sync workflow.
Any other supported fields you want to populate (Short name, Description, Serial, Code, Manufacturer, Model, etc.).
2. Verify Locations exist
Every Asset must reference a valid Location. Before the Asset import, confirm all referenced Locations exist by calling GET /api/customers/locations. Create any missing Locations first.
3. Import in dependency order
If your data includes a parent/child hierarchy, you must import top-level Assets before their children. A child's POST can reference its parent only after the parent exists in Mobaro. The simplest pattern: sort your source data by hierarchy depth, then iterate top-down.
Critical: Importing a child before its parent will return an error or create an orphaned Asset (parent not set). Always sort by depth first. If you're using External IDs from your source system, build a map of {externalId → Mobaro ID} as you go and use it to resolve parent references on subsequent inserts.
4. Verify after import
After the import completes, pull the Asset list (GET /api/customers/assets) and reconcile against your source data. Spot-check Children and Descendants counts on key parent Assets to confirm hierarchies are intact. See Asset hierarchies and parent/child relationships for what the counts should look like.
Worked example: create a single Asset
A minimal POST to create a child Asset under an existing parent:
curl "https://app.mobaro.com/api/customers/assets" \
--request POST \
--header "Content-Type: application/json" \
--header "X-Api-Key: YOUR_SECRET_TOKEN" \
--data '{
"name": "MCC1",
"shortName": "MCC1",
"description": "Maintenance Control Panel 1",
"externalId": "MCC1-GC-001",
"location": "GALAXY_COASTER_LOCATION_ID",
"parent": "CONTROL_PANELS_ASSET_ID"
}'
Note: Field names shown are illustrative. Refer to the official Asset endpoint reference for the exact request schema, including required vs. optional fields and accepted value types.
Common gotchas
Watch out for these issues, which account for most "my import didn't work the way I expected" tickets:
Locations must exist before Assets — an Asset's Location reference is required and must be a real Location in Mobaro at the time of the POST.
Parents must exist before children — sort your source data by hierarchy depth and import top-down.
External IDs are your idempotency anchor — without them, re-running an import creates duplicate Assets. With them, you can detect existing records and switch to
PUTinstead ofPOST.Rate limiting — the API throttles requests under high load. Watch for
429and503responses; back off and retry. Sequential imports with a small delay (e.g., 100ms between requests) usually avoid this.Hierarchy is per Location — an Asset's parent must be at the same Location as the Asset itself. Cross-Location parenting is not supported.
Deletions don't have an undo — there's no soft-delete or restore. Always test deletion logic in a non-production environment first; for production cleanup, log every delete to a separate file.
Best practices
Build for idempotency from day one
A re-runnable import script is one that can be safely re-executed without creating duplicates or unintended changes. The pattern: for each source record, check by External ID whether the Asset already exists; POST if not, PUT if it does. This makes the import a sync rather than a one-shot operation.
Test with a representative subset first
Before importing thousands of Assets, run the script against ten or twenty records that include the trickiest cases (deepest hierarchies, edge-case names, optional fields populated). If those work, the rest will.
Use a dry-run mode
Add a flag to your script that processes the source data and logs what would be imported, without actually issuing POSTs. Reviewing the dry-run output catches malformed records, missing parents, and Location-mismatch errors before any data lands in Mobaro.
Test in a non-production environment when possible
If you have access to a staging or sandbox Mobaro environment, validate large imports there before running against production. If not, scope your initial production import to a single Location.
Best practice: Treat your Asset library like code. Keep your source data and import scripts in version control. Tag commits before each major import. If something goes wrong, you can reconstruct the prior state and fix forward without scrambling.
See also
Getting started with the Mobaro API — auth, headers, and your first request.
Creating and Managing API Keys — generate the key your import script will use.
Understanding API access scopes and limitations — what your key can and can't do.
Mobaro API parameter reference — pagination, filtering, and date filters.
Understanding IDs in Mobaro — for the difference between Mobaro IDs and External IDs.
Creating an Asset — for the UI-based create flow.
Asset hierarchies and parent/child relationships — for understanding the data model you're populating.
Frequently asked questions
Q: Is there a CSV import UI for Assets?
A: Not currently. Bulk Asset operations are done through the API. If you have a CSV, the typical flow is to write a small script that reads the CSV and posts each row to the Asset endpoint. The Mobaro Power Automate connector can also help for simpler workflows.
Q: Can I import Assets in parallel for speed?
A: Sequential imports are recommended. Parallel posting can hit rate limits and creates ordering problems for hierarchies — a child can race ahead of its parent. For a few thousand Assets, sequential imports with a small delay are fast enough and far less error-prone.
Q: What happens if I post the same Asset twice?
A: You get two Assets with the same name. Mobaro doesn't enforce name uniqueness on Assets. Use External IDs and check before each POST to avoid duplicates.
Q: Can the API set the parent Asset?
A: Yes. The parent reference is part of the Asset payload at create time, and can be updated via PUT later. The parent must be an existing Asset at the same Location.
Q: How do I get the IDs of existing Assets?
A: Call GET /api/customers/assets with appropriate filters. Each Asset in the response includes its Mobaro ID and any External ID you've set. Build a lookup map in your script as you process the response.
Q: Can I use Power Automate instead of writing a script?
A: Yes for many workflows. The Mobaro Power Automate connector covers common operations and is great for low/no-code automation. For complex bulk imports — especially with hierarchy resolution — a custom script is usually faster and easier to debug.
Q: Can I bulk delete Assets via the API?
A: There's no batch delete endpoint. Deletes are issued one Asset at a time via DELETE /api/customers/assets/{id}. Be deliberate — there's no undo.