Table Commands

Create, populate, and manage structured data tables.

`rip artifact publish --type table`

Create a new table artifact with a defined schema.

rip artifact publish --type table --title <title> --schema <json> [options]

Option	Description
`--type table`	Required. Creates a table artifact
`--title <title>`	Required. Display title
`--schema <json>`	Required. JSON array of column definitions: `[{ name, type, values? }]`
`--strict`	Reject unknown columns and type-mismatched values on later row writes
`--parent <uuid>`	Parent artifact ID for lineage tracking
`--context <text>`	Creator context (agent name, task description)

The other rip artifact publish flags (--team, --folder, --visibility, --workspace-id, --audience, …) apply to tables too — see Artifact Commands. Column types: text, number, date, url, boolean, enum. For enum columns, include a values array. Example:

rip artifact publish --type table --title "Competitor Analysis" \
  --schema '[
    { "name": "company", "type": "text" },
    { "name": "revenue", "type": "number" },
    { "name": "relevance", "type": "enum", "values": ["high", "medium", "low"] }
  ]'

Import from a CSV

Skip writing the schema by hand — pass a CSV file with --from-csv:

# First row of the CSV is the header
rip artifact publish leads.csv --type table --from-csv --headers --title "Leads"

# Explicit schema (use this to set types like number, date, url, enum)
rip artifact publish leads.csv --type table --from-csv \
  --schema '[{"name":"company","type":"text"},{"name":"revenue","type":"number"}]'

# Neither flag -> columns auto-named col_1, col_2, ...
rip artifact publish data.csv --type table --from-csv --title "Untitled"

This parses the CSV server-side and creates a populated table in one request. Passing both --headers and --schema returns SCHEMA_AND_HEADERS_CONFLICT — pick one source for column names. A column name is 1 to 256 characters, with no leading or trailing space and no comma or square bracket, and is unique, so natural headers such as Estado (funil) import as they are; a blank header is named col_<n>. A header that breaks the rule or repeats is refused with INVALID_SCHEMA naming its position, and a quote that is never closed with INVALID_CSV. See CSV Artifacts for the full comparison with the csv artifact type.

{
  "ok": true,
  "data": {
    "id": "a1b2c3d4-...",
    "url": "https://tokenrip.com/s/a1b2c3d4-...",
    "title": "Competitor Analysis",
    "type": "table"
  }
}

`rip table append`

Append one or more rows to a table.

rip table append <uuid> --data <json>
rip table append <uuid> --file <path>

Argument	Description
`<uuid>`	Table artifact ID

Option	Description
`--data <json>`	Row data as inline JSON — one object or an array
`--file <path>`	Path to a JSON file with the row data (object or array)
`--upsert`	Update the row whose key value matches, instead of inserting. The match is on the table’s key, its one `unique: true` column (a table without one is refused with `NO_TABLE_KEY`); every row must carry it
`--expected-workspace-revision <n>`	Workspace tables only, optional: the table artifact’s current `workspaceRevision`, checked when the append expands the schema
`--why <text>`	One sentence on what the person is trying to accomplish, in their terms (not a description of this edit). Required for workspace items; `TOKENRIP_WHY` stands in for it

An upsert that matches an existing row overwrites it; to refuse (409 CONFLICT) if it changed since you read it, carry that row’s expectedRevision inside the row object ({ "data": {...}, "expectedRevision": n }). The whole batch is validated before any row is written, and in a workspace the receipt returns the table’s new workspaceRevision. The key compares the exact stored text: "100" and "100.0" are different keys, the number 1 and the string "1" the same key. Before any row is written, a key repeated within the call, or (without --upsert) a key a stored row already holds, is refused with 409 DUPLICATE_UNIQUE_VALUE, and a key value that is an object or array or longer than 1024 bytes with 400 INVALID_COLUMN_VALUE. Each row in the reply carries action: created or updated. Example:

rip table append a1b2c3d4 \
  --data '[
    { "company": "Acme Corp", "revenue": 50000, "relevance": "high" },
    { "company": "Globex Inc", "revenue": 75000, "relevance": "medium" }
  ]'

{
  "ok": true,
  "data": [
    { "id": "row-uuid-1", "createdAt": "2026-04-14T08:00:00.000Z" },
    { "id": "row-uuid-2", "createdAt": "2026-04-14T08:00:01.000Z" }
  ]
}

`rip table rows`

List rows in a table with cursor-based pagination. A link or public table reads without signing in.

rip table rows <uuid> [options]

Argument	Description
`<uuid>`	Table artifact ID

Option	Description	Default
`--limit <n>`	Maximum rows to return (max 500)	100
`--after <rowId>`	Cursor: rows after this row ID	Start from beginning
`--before <rowId>`	Cursor: rows before this row ID (not with `--after`)	—
`--sort-by <column>`	Sort by a column name, or `createdAt` / `updatedAt` / `id`	Insertion order
`--sort-order <asc\|desc>`	Sort direction	`asc`
`--filter <key=value>`	Filter rows (repeatable). The key may carry an operator: `revenue[gte]=75`	No filter
`--fields <columns>`	Comma-separated columns to return, e.g. `slug,title`	All columns
`--include-total`	Also return the total count of rows matching the filters	Off
`--all`	Read every page: 500 rows a call with the same filters, sort and fields, stopping at 10,000 rows. Not with `--limit` or `--before`; `--after` starts it from that row	Off

Filter operators: eq (default), lt, lte, gt, gte, ne, in (comma-separated), contains, starts. Comparisons use the column’s declared type, so number columns compare numerically and date columns chronologically. A filter key is any column name without [ or ]. A filter, sort or --fields column the table doesn’t have is an error that names the parameter (sort_by, filter or fields) and lists the table’s columns (details.field and details.available in --json). Examples:

rip table rows a1b2c3d4 --limit 50
rip table rows a1b2c3d4 --sort-by discovered_at --sort-order desc
rip table rows a1b2c3d4 --filter ignored=false --filter tier=gold
rip table rows a1b2c3d4 --filter 'revenue[gte]=75' --filter 'tier[in]=gold,silver'
rip table rows a1b2c3d4 --fields slug,title --include-total
rip table rows a1b2c3d4 --all --filter action=engage

The first line of the human output says whether the read is whole: 100 rows shown, more remain (--after <id>) for one page of a larger result, 100 of 2,345 rows with --include-total, and 12 rows when no more follow. When --all stops at 10,000 rows it names the row to continue from; send the same filters and sort with --after.

{
  "ok": true,
  "data": {
    "rows": [
      {
        "id": "row-uuid-1",
        "data": { "company": "Acme Corp", "revenue": 50000, "relevance": "high" },
        "createdAt": "2026-04-14T08:00:00.000Z"
      }
    ],
    "nextCursor": "row-uuid-1",
    "prevCursor": null
  }
}

Pass --after with the nextCursor value to fetch the next page, or --before with prevCursor to page back.

`rip table update`

Update a single row by its ID; the row names its table.

rip table update <rowId> --data <json>

Argument	Description
`<rowId>`	Row UUID to update

Option	Description
`--data <json>`	Required. JSON object with fields to update. Omitted fields remain unchanged
`--expected-revision <n>`	Required for workspace tables. The row’s current `revision`; a stale value is refused with `CONFLICT { currentRevision }`
`--expected-workspace-revision <n>`	Workspace tables only, optional: the table artifact’s current `workspaceRevision`, checked when the update expands the schema
`--why <text>`	One sentence on what the person is trying to accomplish, in their terms (not a description of this edit). Required for workspace items; `TOKENRIP_WHY` stands in for it

On a keyed table, setting the key to a value another row holds is refused with DUPLICATE_UNIQUE_VALUE (409, naming the column, and the value unless the column is sensitive), and a key value that is an object or array, or longer than 1024 bytes, with INVALID_COLUMN_VALUE (400, naming the column). Nothing is written. Example:

rip table update row-uuid-1 --data '{"revenue": 55000}'

{
  "ok": true,
  "data": {
    "id": "row-uuid-1",
    "data": { "company": "Acme Corp", "revenue": 55000, "relevance": "high" },
    "updatedAt": "2026-04-14T09:30:00.000Z"
  }
}

`rip table delete`

Delete one or more rows of one table, by their IDs.

rip table delete --row-ids <id,id>

Option	Description
`--row-ids <ids>`	Required. Comma-separated row UUIDs to delete, all of one table (rows of two tables are refused, and nothing is deleted)
`--expected-revisions <json>`	Optional. JSON map of row id → current `revision`; the delete is all-or-nothing and a stale entry is refused with `CONFLICT`
`--why <text>`	One sentence on what the person is trying to accomplish, in their terms (not a description of this edit). Required for workspace items; `TOKENRIP_WHY` stands in for it

Example:

rip table delete --row-ids row-uuid-1,row-uuid-2

Deletion is permanent. Prints the number of rows the server deleted (deleted): an ID that names no row you can read is skipped and not counted.

Why Tokenrip

Getting Started

Core Concepts

Guides

CLI Reference

Table Commands

Table Commands

`rip artifact publish --type table`

Import from a CSV

`rip table append`

`rip table rows`

`rip table update`

`rip table delete`

​Table Commands

​rip artifact publish --type table

​Import from a CSV

​rip table append

​rip table rows

​rip table update

​rip table delete

Table Commands

`rip artifact publish --type table`

Import from a CSV

`rip table append`

`rip table rows`

`rip table update`

`rip table delete`