Data Models

Documentation Index

Fetch the complete documentation index at: https://ekso.dev/llms.txt

Use this file to discover all available pages before exploring further.

Every shape that crosses the Ekso API / SDK / CLI boundary lives here with a copy-pasteable JSON example, a field table, and a list of where it’s used. One source of truth — referenced from API endpoints, SDK methods, CLI commands, and migration guides.

​

How to find what you need

If you’re new to Ekso’s domain, start with the Guides → Core concepts — it explains what a container, item, board, and cycle are before you have to read their JSON shape.

​

Anatomy of a page

Every model page has the same four sections:

1. Sample JSON — a complete, realistic request body you can copy and edit. Server-set fields (see below) are omitted from the example so the JSON shows what you send, not what comes back.
2. What Ekso fills in — for models with significant server-managed state (DataItem is the obvious one), a callout listing fields you’ll receive in the response that you didn’t pass on the request.
3. Fields — every property with type, required-or-not, and notes. Cross-references link to other model pages.
4. Used by — request and response endpoints that take or return this shape, plus the matching CLI branch.

​

Conventions

Things that hold across every page in this section.

​

System fields are server-set

Every model carries the same eight system fields — they’re set by the server, not by you, and don’t appear in request examples: Some models layer additional server-managed fields on top — DataItem.sequence, DataItem.clockStart, DataContainer.lastSequence and so on. Each model page calls these out in its What Ekso fills in section.

​

Required vs Optional comes from validators

The OpenAPI spec marks every property optional (a quirk of how System.Text.Json defaults serialise .NET records). The authoritative source for required-ness is the server-side validator that runs before any write. The field table on each page reflects validator rules — **Required** means the API will reject your request with a 422 if you omit it.

​

Enums on the wire are integers

Enums travel as integers over HTTP and in JSON. The SDK exposes them as typed enums (compiled-in safety). The CLI accepts either the integer or the variant name depending on the command — check --help. The single source of truth for every enum’s variant names and values is the Constants page. Schema field tables link directly into the right anchor — for example, [ContentOwner](/data-model/constants#content-owner) jumps you straight to the value list.

​

Meta is the lossless free-form bag

Several models carry a meta array for free-form key/value metadata that doesn’t fit a typed field. Renders in field tables as array<{ key: string, value: string }>. Used heavily by the migration tool to preserve source-platform data that has no first-class Ekso shape (e.g. meta.jira_affects_versions[]).

​

DataItem.Field[] is the value bag for typed fields

Unlike most models, DataItem keeps almost no human attributes as top-level properties. Name, Description, Status, Priority, Severity, Resolution — all live in field[] as DataItemFieldValue { id, data } entries. The id references a process-defined field (system or custom); the data is the value. See DataItem and DataItemFieldValue for the full shape.

​

Where to next

• Constants — every enum referenced by the data models, in one place.
• Core models — DataContainer · DataItem · DataAnnotation · DataFile · DataLink · DataBoard · DataCycle · DataArea
• API Reference — the underlying HTTP routes that take and return these shapes.
• CLI — ekso commands that operate on these models.
• SDK — typed C# client wrapping the same surface.
• Migrate — pull data from Jira / Linear / Azure DevOps / Zendesk / Gemini into these shapes.