Use this file to discover all available pages before exploring further.
All endpoints sit under /v1/tasks/:taskId/.... taskId is the workspace task UUID (or, for child workflows, parent:step:slug — the controllers split on : where they need the root id).Endpoints group into four families:
Lifecycle — what the UI renders and how the user responds (/ui, /snapshots, /action, /row-action).
Events — append-only timeline used for reasoning streams and audit (/events).
Files — upload, list, download, and provider-tagged ingest under /files.
Data ingest — structured JSON payload submission under /data/ingest.
Composes getTask + getNextStep from api-workspace into a single UIState payload that ui-tenant can render directly. The container resolves the tenant context from the task’s tenantId, auto-refreshing on cache mismatch — so the dev/e2e wipe-and-reseed flow works without restarting the process.Response (sketch)
Pure pass-through of api-workspace’s /snapshots endpoint — what was shown + decided at each completed step. Fetched on demand when the user clicks a completed step in the sidebar.Response — Record<string, StepSnapshot> keyed by step id.
Non-terminal row action — edit_cell or reject_row — forwarded to api-workspace as a user_action signal whose kind is row_action. Workflow handlers drain these via on_row_action (see UI and Temporal signals).Body — TaskRowActionDto:
Internal producer endpoint. When NTRO_INTERNAL_EVENTS_KEY is set, requests must include x-ntro-events-key: <secret> — typically only ntro-worker emits to this endpoint.Body — TaskEventDto:
Returns up to 20 documents associated with the task, ordered by upload time descending. Used by the “viewing completed step” mode to find files attached to a previous file-upload step. Filter by source to scope to one runbook source slug.Filtering by taskId keeps the per-source list from leaking duplicate file rows across wipe-and-reseed cycles.Response
Bytes inline in the request body (typically base64-encoded). NOT advertised to agents in next_step — sandboxed agents often can’t reach this URL. Same persist + signal flow as the agent path.Body — UploadFileDto:
Field
Required
Notes
source
Yes
Stable source identifier — workflow activities query by this.
data
Yes
Base64 of the file bytes.
fileName
No
Optional override; otherwise derived.
contentType
No
MIME type; guessed from filename if omitted.
period
No
Period qualifier ("YYYY-MM").
schemaSlug
No
Extraction schema slug used downstream.
signalTaskId / signalName
No
Workflow ID + signal name to fire after persist. From next_step.args.
Response — UploadResult describing the persisted document + any side effects.
Provider-tagged file reference; api-tenant fetches the bytes server-side. This is what next_step’s submit_file action tells agents to use.Body — IngestFileDto. Same fields as the upload DTO but with fileRef instead of data:
The FileFetcher validates per-provider fields. Adding a new provider doesn’t require touching the DTO.Response — UploadResult (same shape as the upload path).
Streams the bytes of a previously-uploaded document. Used by the “viewing completed step” mode to let the user re-download a file submitted earlier. taskId is in the route for symmetry with the upload paths but isn’t enforced at the row level — documentRef is already a UUID.Response — raw bytes with Content-Type from the stored row and Content-Disposition: attachment.