Assets

Assets are the physical things that make up your network: sections of rail, switches, crossings, structures, and their components. The Asset model is the backbone of your data. Most other models (defects, measurements, notifications) attach to an asset by its identifier, so import your assets first, with stable identifiers.

At a glance

• Represents: a physical asset or component on the network
• Body: a JSON array of asset objects
• Keyed by: id — your external identifier, and the upsert key
• Belongs to: a sub-area (subAreaId)
• Referenced by: defects, track measurements, notifications, and more

Tip

The full field list, required vs. optional flags, and runnable example payloads (standalone, parent reference, and nested) are in the API Reference under Asset Import.

What it represents

Each asset records what the thing is and where it sits:

• What — a small set of classifiers: a category and type (e.g. a rail vs. a switch), a status, and a name.
• Where — the shared geolocation concept, describing the asset’s position along the network.

Because assets anchor so much other data, an asset’s identifier matters most. Choose something stable from your source system: every defect, measurement, and prediction you later import refers back to it.

Hierarchy

Assets form a tree: a track section contains components, a switch belongs to a layout, and so on. Express the parent/child relationship two ways:

• By reference — give a child an identifier pointing at its parent. Parent and child can be sent in the same import.
• By nesting — embed child assets inside a parent.

Pick whichever fits your source data, and don’t express the same relationship both ways. The hierarchy lets the platform roll condition and work up from components to the assets that contain them.

Properties

Beyond the standard classifiers, assets can carry custom attributes: name/value pairs stored against the asset. Use these for source-system fields that don’t map onto a standard asset concept, so you keep information that matters to your team.

Using it

• Import (or at least define the identifiers for) your assets before the models that reference them — otherwise those references resolve to nothing.
• Keep identifiers stable across imports; changing an asset’s id creates a new asset rather than updating the existing one.
• Re-importing is safe: an asset with an existing id is updated in place.
• A reference to a category or type the platform doesn’t recognise passes request validation but fails at job time — see Common Errors.