# Current CLI reference

`current` is the command line interface for the Current API. Commands are
generated from the API's OpenAPI schema, so every API operation is available.

## Setup

```bash
pip install current-cli
current login you@example.com                          # magic-link sign in, stores the token
current config set default_workspace <workspace-uuid>  # used when --workspace is omitted
```

The CLI speaks to `https://api.current.orinlabs.ai` by default. For another
server (for example local development), set
`current config set base_url http://localhost:8000`.

The auth token is stored in `~/.config/current-cli/config.json` and sent as
`Authorization: Token <token>`. `CURRENT_API_URL` overrides the base URL.

## Conventions

- Path parameters are positional arguments, shown below as `<name>`.
- Query parameters are `--options`.
- Request bodies are JSON, passed with `--data`: inline (`--data '{"name": "x"}'`),
  from a file (`--data @body.json`), or from stdin (`--data -`).
- Responses print as JSON on stdout. API errors print to stderr and exit 1.
- `--schema <path-or-url>` (or `CURRENT_SCHEMA`) rebuilds the commands from a
  different schema, for example `<base-url>/api/schema/` for a live server.
- Every command supports `--help`.

## Commands

### current accounts auth logout create

Invalidate the current user's auth token.

POST /api/accounts/auth/logout/

### current accounts auth magic-link create

Request a magic sign-in link. Creates the user if they don't exist.

POST /api/accounts/auth/magic-link/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current accounts auth me retrieve

Current user with workspace memberships.

GET /api/accounts/auth/me/

### current accounts auth mfa admin-reset create

Superadmin-only: clear a user's TOTP enrollment so they can enroll a
new device, for when they've lost their authenticator app. There are no
recovery codes, so this is the only way back in for such a user.

POST /api/accounts/auth/mfa/admin-reset/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current accounts auth mfa confirm create

Confirm enrollment with a code from the authenticator app. Mid-login,
this also finishes sign-in (a confirmed device is proof of the second
factor); from Account Settings, it just turns MFA on.

POST /api/accounts/auth/mfa/confirm/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current accounts auth mfa disable create

Turn off TOTP for the current user. Refused when MFA is still
required for this account (platform superadmin, a workspace admin
anywhere, or a workspace that requires it of members) — the setting
would just be silently re-enforced at the next sign-in otherwise.

POST /api/accounts/auth/mfa/disable/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current accounts auth mfa setup create

Start (or restart) TOTP enrollment: mints a new secret and returns
the otpauth:// URI for the authenticator app's QR scanner. Callable
mid-login (with the pending ticket) or from Account Settings (while
authenticated) — the secret isn't active until ``confirm`` succeeds.

POST /api/accounts/auth/mfa/setup/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current accounts auth mfa verify create

Complete sign-in with a code from an already-enrolled authenticator
app, exchanging the pending-login ticket for a real auth token.

POST /api/accounts/auth/mfa/verify/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current accounts auth verify create

Exchange a magic-link token for an auth token — or, when the account
needs a second factor, a short-lived ticket for the MFA challenge/setup
step instead. A real auth token is never issued before that second
factor is satisfied.

POST /api/accounts/auth/verify/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current config get <key>

Print one configuration value.

### current config list

Show all configuration values.

### current config set <key> <value>

Set one configuration value.

### current config unset <key>

Remove one configuration value.

### current contacts add_address create <id>

POST /api/contacts/contacts/{id}/add_address/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current contacts addresses destroy <id> <address_id>

Remove an address. Admin-only regardless of contact type or
verification state — a member can neither see nor mutate addresses.

DELETE /api/contacts/contacts/{id}/addresses/{address_id}/

### current contacts addresses verify create <id> <address_id>

Admin-only: mark an address as platform-verified. Verification is
what makes a membership-linked address approval-capable.

POST /api/contacts/contacts/{id}/addresses/{address_id}/verify/

### current contacts create

POST /api/contacts/contacts/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current contacts destroy <id>

DELETE /api/contacts/contacts/{id}/

### current contacts list

Offset/limit page, ordered by name (the model's own
``Meta.ordering``) so offsets stay stable across pages — a real
workspace directory can hold far more contacts than fit in one
response.

GET /api/contacts/contacts/

Options:
- `--limit` - Max contacts per page (default 25, cap 100)
- `--offset` - Page offset (default 0)
- `--search` - Case-insensitive match against name, company, role, or any address value
- `--workspace` - Filter by workspace UUID

### current contacts partial-update <id>

PATCH /api/contacts/contacts/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current contacts retrieve <id>

GET /api/contacts/contacts/{id}/

### current contacts update <id>

PUT /api/contacts/contacts/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current docs

Print a markdown reference of every command, for LLMs and humans.

### current files delete post

Delete workspace files. The bucket is versioned, so this writes
delete markers — recoverable by an operator, invisible to the portal.

POST /api/files/delete/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current files download-url post

POST {workspace, path} -> {url, path}; subclasses pick the verb.

POST /api/files/download-url/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current files download-zip post

Zip one or more workspace files, and/or whole folders (given as a
path ending in "/"), and stream the archive back. See MAX_ZIP_* for
why this is bounded, unlike the presigned-URL endpoints above.

POST /api/files/download-zip/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current files list

GET /api/files/

Options:
- `--prefix` - Narrow to one tree, e.g. company/ or projects/<id>/
- `--workspace` - Workspace UUID

### current files preview-url post

A URL the browser shows in place, rather than downloads.

The same object ``files_download_url`` hands over, signed instead with
the content type its format calls for and an inline disposition, which
is what a viewer needs to display it. A format the portal does not
render inline stays a download. ``storage.preview_url`` holds why a
plain presigned GET is not enough.

POST /api/files/preview-url/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current files upload-url post

POST {workspace, path} -> {url, path}; subclasses pick the verb.

POST /api/files/upload-url/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current inboxes allow-lists create <inbox_id>

Inbox-scoped AgentMail receive and send allow lists.

Every workspace member can inspect the effective entries. Only workspace
admins can add or remove entries, matching other integration settings.

POST /api/inboxes/inboxes/{inbox_id}/allow-lists/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current inboxes allow-lists destroy <inbox_id>

Inbox-scoped AgentMail receive and send allow lists.

Every workspace member can inspect the effective entries. Only workspace
admins can add or remove entries, matching other integration settings.

DELETE /api/inboxes/inboxes/{inbox_id}/allow-lists/

Options:
- `--direction` - AgentMail allow-list direction
- `--entry` - Email address or domain to remove

### current inboxes allow-lists retrieve <inbox_id>

Inbox-scoped AgentMail receive and send allow lists.

Every workspace member can inspect the effective entries. Only workspace
admins can add or remove entries, matching other integration settings.

GET /api/inboxes/inboxes/{inbox_id}/allow-lists/

### current inboxes list

List (and lazily provision) the workspace's inboxes, one per role.

GET /api/inboxes/inboxes/

Options:
- `--workspace` - Workspace UUID

### current integrations connections authorize create

Start an OAuth flow: returns the provider authorize URL to redirect to.

POST /api/integrations/connections/authorize/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations connections basecamp-accounts list <id>

Basecamp accounts visible to the connected identity.

GET /api/integrations/connections/{id}/basecamp-accounts/

### current integrations connections channels list <id>

List public Slack channels — verifies a Slack connection works.

GET /api/integrations/connections/{id}/channels/

### current integrations connections connect-api-user create

Connect Salesforce as an API-only user.

These users cannot reach an OAuth consent screen, so there is no
redirect to hand the browser: the credentials arrive here, and one
live login proves them before anything is stored.

POST /api/integrations/connections/connect-api-user/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations connections connect-client-credentials create

Connect Salesforce with a connected app from the customer's org.

A server-to-server grant: the app names a Run As user, so there is no
consent screen and no user credential. The app is not ours and not
server-wide, so its client id and secret are stored per workspace.

POST /api/integrations/connections/connect-client-credentials/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations connections destroy <id>

Workspace integration connections. Created via the OAuth callback, or
via connect-api-user for providers that support credentials; any member
can list, only admins can connect, pause a sync, or disconnect.

DELETE /api/integrations/connections/{id}/

### current integrations connections list

Workspace integration connections. Created via the OAuth callback, or
via connect-api-user for providers that support credentials; any member
can list, only admins can connect, pause a sync, or disconnect.

GET /api/integrations/connections/

Options:
- `--workspace` - Filter by workspace UUID

### current integrations connections pause-sync create <id>

Stop the scheduled sync for this connection.

The connection stays active: workflow tools, webhooks, and manual
reads keep working. Only the recurring job stops. Data already in the
workspace is left alone.

POST /api/integrations/connections/{id}/pause-sync/

### current integrations connections providers list

All known providers and whether OAuth credentials are configured.

GET /api/integrations/connections/providers/

### current integrations connections resume-sync create <id>

Let the scheduled sync run again.

The sync keeps no watermark, so the next run reads the current state
of the provider and closes whatever gap the pause opened.

POST /api/integrations/connections/{id}/resume-sync/

### current integrations connections select-basecamp-account create <id>

Choose the one Basecamp account synchronized into this workspace.

POST /api/integrations/connections/{id}/select-basecamp-account/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations connections teams-conversations list <id>

Teams conversations the bot has seen, derived from the
observations ledger (there is no conversation table and the Bot
Connector has no listing API). Personal DMs are excluded — this
powers the approval-routing FYI picker.

GET /api/integrations/connections/{id}/teams-conversations/

### current integrations messaging files manifest post

Hydration manifest for the messaging agent's sandbox.

Same shape as the run manifest above, but workspace-wide: a chat
message can turn out to be about any project, and unlike a workflow
definition the agent declares no inputs, so it gets the company tree
plus every project tree and decides for itself what it needs.

An index, not a copy: the sandbox fetches a file's bytes only when the
model reads that file. That is what lets this stay workspace-wide now
that a workspace mirrors its Sitetracker documents — gigabytes of
scans that ``read_file`` could only refuse, and that an attachment
reads here from object storage rather than from the sandbox.

``truncated`` says the workspace holds more than this answer names, so
the agent can tell a user "I cannot see all of your files" instead of
reporting a file it was never given as one the workspace does not have.

POST, for a read, because the job-token permission class reads the
workspace id out of the request body — the same contract every other
messaging-job endpoint uses.

POST /api/integrations/messaging/files/manifest/

### current integrations messaging files upload-urls post

PUT URLs for the files attached to the message the agent is
answering, so a workflow it starts on a project can read them.

Narrow on purpose: the only writable tree is the named project's
``requests/`` folder. The agent's sandbox holds the attachment bytes
but no storage credentials, and the platform no longer holds the bytes
by the time the agent decides to start a run (a Teams download URL
expires within minutes), so the sandbox uploads them itself.

POST /api/integrations/messaging/files/upload-urls/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations messaging history post

What was already said in this conversation, oldest last.

The agent is dispatched with one message and no memory of the last
one, so without this every turn answers out of context — "send it to
the same person" has no referent. Neither provider will give the
history back (see ``integrations.transcript``), so this reads current's
own ledger: the messages people sent the bot, and the replies the bot
sent them.

Unlike the send paths this needs no anti-spoofing guard. It only ever
reads the calling workspace's own observations, so a forged
conversation id reads nothing rather than reaching another tenant.

POST /api/integrations/messaging/history/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations messaging react post

Add an emoji reaction to the message a reply_ref points at.

Email has no reactions and is refused. An email job is not offered the
``react`` tool at all, so reaching here means a caller sent something it
should not have.

POST /api/integrations/messaging/react/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations messaging respond post

Relay the agent's reply, and any workspace files it chose to attach,
into the conversation the message came from — see :func:`send_reply`.

POST /api/integrations/messaging/respond/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations messaging start-workflow post

Run one of the workspace's workflows on demand, because a person asked
for it in chat.

This is not a trigger: no binding fires, and nothing here decides on its
own that a message deserves a workflow — the messaging agent does, the
same way a person clicks "run now" in the portal. The conversation rides
onto the run, so the workflow reports back into the thread that asked.

POST /api/integrations/messaging/start-workflow/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations messaging stream post

Live progress UI for a sandbox agent run; the final reply is NOT part
of it — the agent posts that as a normal message through the respond
endpoint afterwards.

Slack: ``start`` opens a "thinking steps" streaming message in the
thread (plan mode: task cards grouped under one card), ``append``
streams task_update/plan_update chunks into it, ``stop`` settles it.

Teams: ``start`` sends one Adaptive Card (compact status header plus a
toggleable activity section) and returns its activity id as ``ts``;
``append``/``stop`` replace the card in full, rebuilt from the chunks —
the sandbox always sends its complete state, so the relay stays
stateless.

Email has no live message to evolve and is refused. An email job builds
no reporter, so reaching here means a caller sent something it should
not have.

POST /api/integrations/messaging/stream/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current integrations teams app-package get

Download the Teams app package (manifest + icons) as a zip.

The bot is a single-tenant Azure registration in the platform's home
tenant; customer tenants get the bot by uploading this package to their
Teams org catalog — no Azure work on their side. Admin-gated like the
rest of the integration surface.

GET /api/integrations/teams/app-package/

Options:
- `--workspace` - Workspace UUID; the caller must be an admin of it.

### current login <email>

Sign in with a magic link and store the auth token.

### current logout

Invalidate the auth token on the server and forget it locally.

### current observations by-project retrieve

Which projects hold the matching observations: how many each holds and when the latest happened. Takes the same filters as the list. A project absent from the result has no matching activity at all — not old activity. To find projects that have gone quiet, leave the window open, sort by latest_occurred_at and compare each project's latest to your cutoff; never infer a quiet set by subtracting a recent one. Pages by project: read total_projects and follow next_offset.

GET /api/observations/observations/by-project/

Options:
- `--facets` - Add 'by_source' to the response: how many matching observations each source holds. Costs one extra grouped query, so it is opt-in — ask for it when you need to know this workspace's actual mix rather than assume one.
- `--ids` - Comma-separated observation UUIDs
- `--limit` - Projects per page (default 100, cap 200)
- `--offset` - Project page offset (default 0)
- `--order` - Sort key. Defaults to -occurred_at when project, since or until is given, because a window is a question about world time, and to -observed_at otherwise, because the stream is a work queue ordered by when Current learned of things.
- `--project` - Filter by project UUID
- `--revisions` - Observations are immutable, so an edited Chatter post is a second row sharing payload.record_key. 'all' (default) returns every revision, which is what the project audit log shows. 'current' returns only the latest revision of each post or comment, which is what a count of what people said means.
- `--since` - Keep observations that happened at or after this instant. Bounds occurred_at (when it happened in the world), not observed_at (when Current learned of it). ISO-8601; a bare date means the START of that day. A value with no offset is read in the workspace's timezone when exactly one workspace is in scope, otherwise UTC.
- `--sort` - Project order. '-count' (default) puts the busiest first. 'latest_occurred_at' puts the quietest first: the projects whose most recent matching activity is oldest.
- `--source` - Keep only observations from this source; repeat to accept several. Common names work as well as the stored value: 'chatter' finds 'sitetracker_feed'. An unknown source is refused with the recorded ones named, because an empty page would read as 'nothing happened'.
- `--status` - Filter by status (pending/ingested)
- `--until` - Keep observations that happened at or before this instant, inclusive. A bare date means the END of that day, so since=2026-09-01&until=2026-09-14 is the fourteen days a person means by that.
- `--workspace` - Filter by workspace UUID

### current observations create

The workspace observation stream. List/retrieve for members; create is
quick-capture (source=user). No update or delete — content is immutable
and annotations belong to agents. ``project=`` is the project audit log,
newest happening first.

``source``, ``since`` and ``until`` narrow the stream to one kind of
activity in one window of world time; ``by-project`` answers "which
projects" over that same window in one call, instead of paging every row
and grouping them by eye. Page size is capped at 200 whatever you ask
for.

POST /api/observations/observations/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current observations list

The workspace observation stream. List/retrieve for members; create is
quick-capture (source=user). No update or delete — content is immutable
and annotations belong to agents. ``project=`` is the project audit log,
newest happening first.

``source``, ``since`` and ``until`` narrow the stream to one kind of
activity in one window of world time; ``by-project`` answers "which
projects" over that same window in one call, instead of paging every row
and grouping them by eye. Page size is capped at 200 whatever you ask
for.

GET /api/observations/observations/

Options:
- `--facets` - Add 'by_source' to the response: how many matching observations each source holds. Costs one extra grouped query, so it is opt-in — ask for it when you need to know this workspace's actual mix rather than assume one.
- `--ids` - Comma-separated observation UUIDs
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.
- `--order` - Sort key. Defaults to -occurred_at when project, since or until is given, because a window is a question about world time, and to -observed_at otherwise, because the stream is a work queue ordered by when Current learned of things.
- `--project` - Filter by project UUID
- `--revisions` - Observations are immutable, so an edited Chatter post is a second row sharing payload.record_key. 'all' (default) returns every revision, which is what the project audit log shows. 'current' returns only the latest revision of each post or comment, which is what a count of what people said means.
- `--since` - Keep observations that happened at or after this instant. Bounds occurred_at (when it happened in the world), not observed_at (when Current learned of it). ISO-8601; a bare date means the START of that day. A value with no offset is read in the workspace's timezone when exactly one workspace is in scope, otherwise UTC.
- `--source` - Keep only observations from this source; repeat to accept several. Common names work as well as the stored value: 'chatter' finds 'sitetracker_feed'. An unknown source is refused with the recorded ones named, because an empty page would read as 'nothing happened'.
- `--status` - Filter by status (pending/ingested)
- `--until` - Keep observations that happened at or before this instant, inclusive. A bare date means the END of that day, so since=2026-09-01&until=2026-09-14 is the fourteen days a person means by that.
- `--workspace` - Filter by workspace UUID

### current observations retrieve <id>

The workspace observation stream. List/retrieve for members; create is
quick-capture (source=user). No update or delete — content is immutable
and annotations belong to agents. ``project=`` is the project audit log,
newest happening first.

``source``, ``since`` and ``until`` narrow the stream to one kind of
activity in one window of world time; ``by-project`` answers "which
projects" over that same window in one call, instead of paging every row
and grouping them by eye. Page size is capped at 200 whatever you ask
for.

GET /api/observations/observations/{id}/

### current projects closeout retrieve <id>

The project's current closeout review — the review.json a
closeout workflow run wrote to workspace storage, parsed and
validated server-side. ``review`` is null when no run has written
one yet.

GET /api/projects/projects/{id}/closeout/

### current projects create

Projects across the caller's workspaces. Any member can create a
project (including its initial field values); editing the fields of an
existing project is admin-only.

POST /api/projects/projects/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current projects destroy <id>

Projects across the caller's workspaces. Any member can create a
project (including its initial field values); editing the fields of an
existing project is admin-only.

DELETE /api/projects/projects/{id}/

### current projects feed retrieve <id>

The project's field-value write history, newest first.

GET /api/projects/projects/{id}/feed/

Options:
- `--cursor` - Keyset cursor from a previous page
- `--limit` - Max writes per page (default 25)

### current projects field-definitions create

Workspace-level custom field definitions. Only admins can mutate.

POST /api/projects/field-definitions/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current projects field-definitions destroy <id>

Workspace-level custom field definitions. Only admins can mutate.

DELETE /api/projects/field-definitions/{id}/

### current projects field-definitions list

Workspace-level custom field definitions. Only admins can mutate.

GET /api/projects/field-definitions/

Options:
- `--workspace` - Filter by workspace UUID

### current projects field-definitions option_usage retrieve <id>

Count projects whose current value uses each option on this field.

GET /api/projects/field-definitions/{id}/option_usage/

### current projects field-definitions partial-update <id>

Workspace-level custom field definitions. Only admins can mutate.

PATCH /api/projects/field-definitions/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current projects field-definitions retrieve <id>

Workspace-level custom field definitions. Only admins can mutate.

GET /api/projects/field-definitions/{id}/

### current projects field-definitions update <id>

Workspace-level custom field definitions. Only admins can mutate.

PUT /api/projects/field-definitions/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current projects inventory retrieve

Page current field values, optionally narrowed to named keys and
to projects whose values match.

The full project list serializes every field of every project —
megabytes at production scale. This page is the compact census a
chat agent can scan: identity plus the keys it asked for, no
timeline, no provenance.

Filter here rather than page-and-sift: a caller that reads every
page and picks the matches by eye miscounts, and "total" under a
filter is the count it was really after. See state.list_projects.

GET /api/projects/projects/inventory/

Options:
- `--fields` - Field keys to keep; omit to return every current value
- `--filter` - Keep only projects whose current value matches, as 'key:value' (for example 'status:Active'). Repeat for more fields; repeating one key accepts any of its values. An option matches by label, value, or ID. Use 'key:*' for any value (is not blank) and 'key:!' for no value (is blank). A number or date value may lead with '<', '<=', '>', or '>='; two bounds on one key are a range. 'total' counts the matching projects.
- `--limit` - Max projects per page (default 100, max 200)
- `--offset` - Number of projects to skip (default 0)
- `--values` - Read option values as labels (default) or as option IDs
- `--workspace` - Workspace UUID

### current projects list

Projects across the caller's workspaces. Any member can create a
project (including its initial field values); editing the fields of an
existing project is admin-only.

GET /api/projects/projects/

Options:
- `--workspace` - Filter by workspace UUID

### current projects partial-update <id>

Projects across the caller's workspaces. Any member can create a
project (including its initial field values); editing the fields of an
existing project is admin-only.

PATCH /api/projects/projects/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current projects retrieve <id>

Projects across the caller's workspaces. Any member can create a
project (including its initial field values); editing the fields of an
existing project is admin-only.

GET /api/projects/projects/{id}/

### current projects revert create <id>

Append a write restoring the value that preceded the given write.

POST /api/projects/projects/{id}/revert/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current projects search retrieve

Find projects by their current field values (see state.search_projects).

Compact on purpose: the full project list serializes every field
value of every project — megabytes at production scale — which no
chat agent or picker can consume. A hit carries just enough to
choose a project and fetch its detail.

GET /api/projects/projects/search/

Options:
- `--q` - Case-insensitive regular expression; a plain word searches as a keyword
- `--workspace` - Filter by workspace UUID

### current projects update <id>

Projects across the caller's workspaces. Any member can create a
project (including its initial field values); editing the fields of an
existing project is admin-only.

PUT /api/projects/projects/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current reactions create

Thumbs up/down (+ optional reason and comment) on a piece of platform
output.

Reads have two scopes, chosen by the ``scope`` query parameter:

- ``mine`` (the default) — the reactions the caller gave, and nobody
  else's. This is what a plain member gets, whatever they ask for.
- ``workspace`` — every member's reactions, restricted to the workspaces
  the caller is an admin of. A caller who administers no workspace reads
  nothing under this scope; an admin of one workspace does not thereby
  read a workspace where they are only a member.

Author-only is the default rather than the rule because the alternative
breaks the caller that exists. The portal reads this endpoint to draw a
member's own thumb (``getMyReaction``/``getMyReactions`` in
``reactionsLogic.ts``) and takes the first row for a subject as "my
current reaction". Widening reads for admins by default would silently
make an admin's own widget show whichever teammate reacted last. An
explicit ``scope=workspace`` keeps that call path byte-for-byte
unchanged and makes reading a colleague's feedback a deliberate act.

A member is told this: feedback is private from their colleagues, but an
admin of their workspace can read it. That is a weaker promise than the
one this endpoint shipped with, and it is the honest one — an admin has
to be able to see whether the platform's output is any good, and the
alternative in practice was reading the production database.

Create for any member of the workspace — every submission is a new row
(see ``Reaction``). No update or delete: a changed mind is a new
reaction, not an edit to the old one.

POST /api/reactions/reactions/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current reactions list

Thumbs up/down (+ optional reason and comment) on a piece of platform
output.

Reads have two scopes, chosen by the ``scope`` query parameter:

- ``mine`` (the default) — the reactions the caller gave, and nobody
  else's. This is what a plain member gets, whatever they ask for.
- ``workspace`` — every member's reactions, restricted to the workspaces
  the caller is an admin of. A caller who administers no workspace reads
  nothing under this scope; an admin of one workspace does not thereby
  read a workspace where they are only a member.

Author-only is the default rather than the rule because the alternative
breaks the caller that exists. The portal reads this endpoint to draw a
member's own thumb (``getMyReaction``/``getMyReactions`` in
``reactionsLogic.ts``) and takes the first row for a subject as "my
current reaction". Widening reads for admins by default would silently
make an admin's own widget show whichever teammate reacted last. An
explicit ``scope=workspace`` keeps that call path byte-for-byte
unchanged and makes reading a colleague's feedback a deliberate act.

A member is told this: feedback is private from their colleagues, but an
admin of their workspace can read it. That is a weaker promise than the
one this endpoint shipped with, and it is the honest one — an admin has
to be able to see whether the platform's output is any good, and the
alternative in practice was reading the production database.

Create for any member of the workspace — every submission is a new row
(see ``Reaction``). No update or delete: a changed mind is a new
reaction, not an edit to the old one.

GET /api/reactions/reactions/

Options:
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.
- `--project` - Filter by project UUID
- `--scope` - Whose reactions to read. 'mine' (the default) reads your own. 'workspace' reads every member's, and returns rows only from the workspaces you are an admin of.
- `--subject-id` - Filter by subject id
- `--subject-type` - Filter by subject type
- `--subject-version` - Filter by subject version
- `--workspace` - Filter by workspace UUID

### current reactions retrieve <id>

Thumbs up/down (+ optional reason and comment) on a piece of platform
output.

Reads have two scopes, chosen by the ``scope`` query parameter:

- ``mine`` (the default) — the reactions the caller gave, and nobody
  else's. This is what a plain member gets, whatever they ask for.
- ``workspace`` — every member's reactions, restricted to the workspaces
  the caller is an admin of. A caller who administers no workspace reads
  nothing under this scope; an admin of one workspace does not thereby
  read a workspace where they are only a member.

Author-only is the default rather than the rule because the alternative
breaks the caller that exists. The portal reads this endpoint to draw a
member's own thumb (``getMyReaction``/``getMyReactions`` in
``reactionsLogic.ts``) and takes the first row for a subject as "my
current reaction". Widening reads for admins by default would silently
make an admin's own widget show whichever teammate reacted last. An
explicit ``scope=workspace`` keeps that call path byte-for-byte
unchanged and makes reading a colleague's feedback a deliberate act.

A member is told this: feedback is private from their colleagues, but an
admin of their workspace can read it. That is a weaker promise than the
one this endpoint shipped with, and it is the honest one — an admin has
to be able to see whether the platform's output is any good, and the
alternative in practice was reading the production database.

Create for any member of the workspace — every submission is a new row
(see ``Reaction``). No update or delete: a changed mind is a new
reaction, not an edit to the old one.

GET /api/reactions/reactions/{id}/

Options:
- `--scope` - Whose reactions to read. 'mine' (the default) reads your own. 'workspace' reads every member's, and returns rows only from the workspaces you are an admin of.

### current supplier-documents documents extractions list <id>

GET /api/supplier-documents/documents/{id}/extractions/

Options:
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.

### current supplier-documents documents list

GET /api/supplier-documents/documents/

Options:
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.

### current supplier-documents documents record retrieve <id>

GET /api/supplier-documents/documents/{id}/record/

### current supplier-documents documents retrieve <id>

GET /api/supplier-documents/documents/{id}/

### current supplier-documents documents source retrieve <id>

GET /api/supplier-documents/documents/{id}/source/

### current supplier-documents links attach create

POST /api/supplier-documents/links/attach/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents links decision create <id>

POST /api/supplier-documents/links/{id}/decision/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents links list

GET /api/supplier-documents/links/

Options:
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.

### current supplier-documents links retrieve <id>

GET /api/supplier-documents/links/{id}/

### current supplier-documents links revision create <id>

POST /api/supplier-documents/links/{id}/revision/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents relationships attach create

POST /api/supplier-documents/relationships/attach/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents relationships decision create <id>

POST /api/supplier-documents/relationships/{id}/decision/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents relationships list

GET /api/supplier-documents/relationships/

Options:
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.

### current supplier-documents relationships retrieve <id>

GET /api/supplier-documents/relationships/{id}/

### current supplier-documents runs publish create <run_id>

POST /api/supplier-documents/runs/{run_id}/publish/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents sets combined retrieve <id>

GET /api/supplier-documents/sets/{id}/combined/

### current supplier-documents sets links list <id>

GET /api/supplier-documents/sets/{id}/links/

Options:
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.

### current supplier-documents sets list

GET /api/supplier-documents/sets/

Options:
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.

### current supplier-documents sets relationships list <id>

GET /api/supplier-documents/sets/{id}/relationships/

Options:
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.

### current supplier-documents sets retrieve <id>

GET /api/supplier-documents/sets/{id}/

### current supplier-documents suppliers list

GET /api/supplier-documents/suppliers/

Options:
- `--limit` - Number of results to return per page.
- `--offset` - The initial index from which to return the results.

### current supplier-documents suppliers resolve create <id>

POST /api/supplier-documents/suppliers/{id}/resolve/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents suppliers retrieve <id>

GET /api/supplier-documents/suppliers/{id}/

### current supplier-documents workspaces attachments remove create <workspace_id> <attachment_id>

POST /api/supplier-documents/workspaces/{workspace_id}/attachments/{attachment_id}/remove/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents workspaces library retrieve <workspace_id>

GET /api/supplier-documents/workspaces/{workspace_id}/library/

Options:
- `--limit`
- `--offset`
- `--project`
- `--q`
- `--unassigned`

### current supplier-documents workspaces sets attachments create <workspace_id> <set_id>

POST /api/supplier-documents/workspaces/{workspace_id}/sets/{set_id}/attachments/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents workspaces sets attachments source create <workspace_id> <set_id>

POST /api/supplier-documents/workspaces/{workspace_id}/sets/{set_id}/attachments/source/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current supplier-documents workspaces sets review retrieve <workspace_id> <set_id>

GET /api/supplier-documents/workspaces/{workspace_id}/sets/{set_id}/review/

### current tasks create

The caller's personal todos. Incomplete tasks sort before completed ones.

POST /api/tasks/tasks/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current tasks destroy <id>

The caller's personal todos. Incomplete tasks sort before completed ones.

DELETE /api/tasks/tasks/{id}/

### current tasks list

The caller's personal todos. Incomplete tasks sort before completed ones.

GET /api/tasks/tasks/

### current tasks partial-update <id>

The caller's personal todos. Incomplete tasks sort before completed ones.

PATCH /api/tasks/tasks/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current tasks retrieve <id>

The caller's personal todos. Incomplete tasks sort before completed ones.

GET /api/tasks/tasks/{id}/

### current tasks update <id>

The caller's personal todos. Incomplete tasks sort before completed ones.

PUT /api/tasks/tasks/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current vendors create

Vendors across the caller's workspaces. Any member can create and edit.

POST /api/vendors/vendors/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current vendors destroy <id>

Vendors across the caller's workspaces. Any member can create and edit.

DELETE /api/vendors/vendors/{id}/

### current vendors list

Vendors across the caller's workspaces. Any member can create and edit.

GET /api/vendors/vendors/

Options:
- `--limit` - Max vendors per page (default 25, cap 100)
- `--offset` - Page offset (default 0)
- `--project` - Filter by linked project UUID
- `--workspace` - Filter by workspace UUID

### current vendors partial-update <id>

Vendors across the caller's workspaces. Any member can create and edit.

PATCH /api/vendors/vendors/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current vendors retrieve <id>

Vendors across the caller's workspaces. Any member can create and edit.

GET /api/vendors/vendors/{id}/

### current vendors update <id>

Vendors across the caller's workspaces. Any member can create and edit.

PUT /api/vendors/vendors/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current whoami

Show the current user and workspace memberships.

### current workflows compile-condition create

Turn a described field condition into a project_field trigger_config. Saves nothing: the caller reviews the proposal and saves it like any other condition.

POST /api/workflows/workflows/compile-condition/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workflows create

Workflows (actions) across the caller's workspaces. Any member can
read; only admins can create, edit (including enable/disable), or
delete a binding.

POST /api/workflows/workflows/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workflows definitions apply create

Upsert a rendered workflow definition into a workspace and seed a
disabled binding for each trigger it declares.

A definition that still contains an ``emits[]`` key (the removed
record system's declaration) is accepted and the key ignored.

POST /api/workflows/definitions/apply/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workflows definitions list

Applied workflow definitions across the caller's workspaces. The
portal reads this to offer definitions when binding a new trigger;
writes go through the apply endpoint.

GET /api/workflows/definitions/

Options:
- `--workspace` - Filter by workspace UUID

### current workflows definitions retrieve <id>

Applied workflow definitions across the caller's workspaces. The
portal reads this to offer definitions when binding a new trigger;
writes go through the apply endpoint.

GET /api/workflows/definitions/{id}/

### current workflows destroy <id>

Workflows (actions) across the caller's workspaces. Any member can
read; only admins can create, edit (including enable/disable), or
delete a binding.

DELETE /api/workflows/workflows/{id}/

### current workflows list

Workflows (actions) across the caller's workspaces. Any member can
read; only admins can create, edit (including enable/disable), or
delete a binding.

GET /api/workflows/workflows/

Options:
- `--workspace` - Filter by workspace UUID

### current workflows partial-update <id>

Workflows (actions) across the caller's workspaces. Any member can
read; only admins can create, edit (including enable/disable), or
delete a binding.

PATCH /api/workflows/workflows/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workflows retrieve <id>

Workflows (actions) across the caller's workspaces. Any member can
read; only admins can create, edit (including enable/disable), or
delete a binding.

GET /api/workflows/workflows/{id}/

### current workflows runs archive create <id>

Hide the run from the default Actions list. Only finished (terminal-status)
runs may be archived — archiving a run that's still in flight would hide it
while dispatch keeps working on it.

POST /api/workflows/runs/{id}/archive/

### current workflows runs complete create <run_id>

Machine endpoint: the runner reports the run's terminal outcome —
the sole finalization authority (finalization no longer waits for a
terminal step transition). Idempotent: a run that is already terminal
returns 200 with its current state, unchanged.

POST /api/workflows/runs/{run_id}/complete/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workflows runs create

Run history for workflows in the caller's workspaces, with step
transitions inline. POST creates a run of a WorkflowDefinition and
dispatches it. Runs on the same project execute concurrently.

POST /api/workflows/runs/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workflows runs definition retrieve <run_id>

Machine endpoint: the runner fetches its work order — the rendered
definition plus the journal state it needs to resume (step states).

GET /api/workflows/runs/{run_id}/definition/

### current workflows runs files manifest get <run_id>

GET /api/workflows/runs/{run_id}/files/manifest/

### current workflows runs files promote-urls post <run_id>

POST /api/workflows/runs/{run_id}/files/promote-urls/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workflows runs list

An offset/limit page. A run carries its transitions inline, so the
unpaged history was the largest payload this API could return and
grew without bound; a reader now sees a page and the true ``total``
rather than whatever fit.

GET /api/workflows/runs/

Options:
- `--archived` - Filter by archived state. Defaults to false (hides archived runs).
- `--definition` - Filter by definition UUID
- `--limit` - Max runs per page (default 25, cap 100)
- `--offset` - Page offset (default 0)
- `--project` - Filter by project UUID
- `--workflow` - Filter by workflow UUID
- `--workspace` - Filter by workspace UUID

### current workflows runs retrieve <id>

Run history for workflows in the caller's workspaces, with step
transitions inline. POST creates a run of a WorkflowDefinition and
dispatches it. Runs on the same project execute concurrently.

GET /api/workflows/runs/{id}/

### current workflows runs tools invoke create <run_id> <tool_name>

POST /api/workflows/runs/{run_id}/tools/{tool_name}/invoke/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workflows runs transitions create <run_id>

Machine endpoint: the runner journals step state changes. Idempotent —
a duplicate (step_id, status, attempt) returns the existing row with 200.

POST /api/workflows/runs/{run_id}/transitions/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workflows runs unarchive create <id>

Restore an archived run to the default Actions list.

POST /api/workflows/runs/{id}/unarchive/

### current workflows update <id>

Workflows (actions) across the caller's workspaces. Any member can
read; only admins can create, edit (including enable/disable), or
delete a binding.

PUT /api/workflows/workflows/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workspaces create

Workspaces the current user belongs to. Creating one makes you its admin.

POST /api/workspaces/workspaces/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workspaces destroy <id>

Workspaces the current user belongs to. Creating one makes you its admin.

DELETE /api/workspaces/workspaces/{id}/

### current workspaces invites accept create <id>

Accept an invite as the authenticated user. The user must have signed in
(via magic link) with the invited email.

POST /api/workspaces/invites/{id}/accept/

### current workspaces invites create <workspace_id>

Pending invites for a workspace, nested under /workspaces/{workspace_id}/.

POST /api/workspaces/workspaces/{workspace_id}/invites/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workspaces invites destroy <workspace_id> <id>

Pending invites for a workspace, nested under /workspaces/{workspace_id}/.

DELETE /api/workspaces/workspaces/{workspace_id}/invites/{id}/

### current workspaces invites list <workspace_id>

Pending invites for a workspace, nested under /workspaces/{workspace_id}/.

GET /api/workspaces/workspaces/{workspace_id}/invites/

### current workspaces invites retrieve <id>

Invite details for the accept page. The invite id (from the emailed
link) is the capability to view it.

GET /api/workspaces/invites/{id}/

### current workspaces list

Workspaces the current user belongs to. Creating one makes you its admin.

GET /api/workspaces/workspaces/

### current workspaces members destroy <workspace_id> <id>

Memberships of a workspace, nested under /workspaces/{workspace_id}/.

DELETE /api/workspaces/workspaces/{workspace_id}/members/{id}/

### current workspaces members list <workspace_id>

Memberships of a workspace, nested under /workspaces/{workspace_id}/.

GET /api/workspaces/workspaces/{workspace_id}/members/

### current workspaces members partial-update <workspace_id> <id>

Memberships of a workspace, nested under /workspaces/{workspace_id}/.

PATCH /api/workspaces/workspaces/{workspace_id}/members/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workspaces members retrieve <workspace_id> <id>

Memberships of a workspace, nested under /workspaces/{workspace_id}/.

GET /api/workspaces/workspaces/{workspace_id}/members/{id}/

### current workspaces members update <workspace_id> <id>

Memberships of a workspace, nested under /workspaces/{workspace_id}/.

PUT /api/workspaces/workspaces/{workspace_id}/members/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workspaces partial-update <id>

Workspaces the current user belongs to. Creating one makes you its admin.

PATCH /api/workspaces/workspaces/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.

### current workspaces retrieve <id>

Workspaces the current user belongs to. Creating one makes you its admin.

GET /api/workspaces/workspaces/{id}/

### current workspaces update <id>

Workspaces the current user belongs to. Creating one makes you its admin.

PUT /api/workspaces/workspaces/{id}/

Options:
- `--data` (required) - Request body as JSON: inline, @file.json, or - for stdin.
