APIs, terminal, and read-only MCP
Use DART through its APIs and command tools. The same access rules apply to the work screens and these tools.
Application APIs
Developers may need to work with the same records through code instead of a screen. DART provides APIs for its main areas of work. They use the same user identity and access rules as the screens.
Write commands check their fields before saving. Each intended action has a request ID. Retrying the same request does not create a second action.
Version checks stop old data from overwriting newer work. A command must satisfy the rules for the record it changes.
The operations and readiness write routes require a same-origin request. Each body is limited to 64 KB. Errors include a code and a reference ID for support.
| Interface | Purpose |
|---|---|
| GET /api/operations | List incidents the signed-in user may read. |
| GET /api/operations?incident_id=… | Open the selected incident and its permitted records. |
| GET /api/readiness?view=people | List people within the user’s readiness scope. |
| GET /api/readiness?person_id=… | Read a person’s readiness evidence and allowed actions. |
| GET /api/readiness?view=assessment&… | Check a qualification for the requested dates and time zone. |
| /api/equipment | Read or change equipment within the user’s role. |
| /api/reports | Build and download reports within current access. |
| /api/planning | Run planning and inspect saved results. |
| /api/mcp | Read authorized records through the read-only tool interface. |
DART commands and shell work
Some users prefer commands for repeated or file-based work. The terminal lets a user run DART commands. It also supports shell files and file transfers. Command history shows what was requested and returned.
Commands use the same application interfaces as the work screens. Opening the terminal does not grant extra permissions.
Read-only MCP access
A compatible assistant or tool can help inspect records without being allowed to change them. MCP lets a compatible tool read DART through a defined set of actions. This interface is read-only. It can search and inspect records the user is allowed to read.
A signed-in user can create a short-lived MCP key. The key is tied to their person and session. It stops working when it expires or is revoked.
The server checks current access for each read. An expired session or inactive sign-in identity blocks the key.
Define the connection before building it
A person using a screen and a service running on a schedule have different access needs. A service exchange uses a reviewed connection and service account. It has different needs from a person using a work-screen API.
Before connecting a system, define its IDs and field ownership. Agree on retry behavior and errors. Keep enough evidence to compare the source with the result.