Skip to main content
Workspace Objects use the record endpoints below. Platform Objects keep their existing endpoints, such as /v1/workers. These endpoints require Objects enabled and a verified administrator. Reads require the Object’s permission, such as objects.computers:read; writes also require objects.computers:write. Object-definition administration permissions are separate. Access is currently workspace-wide; grants limited to particular Object types are not yet supported. Use the stored collection slug returned by the Object definition, such as computers, for {slug}. The record’s object value uses the singular key, objects.computer. Collection paths are plural kebab-case: objects.purchase_order is served at /v1/objects/purchase-orders. Permissions and tool names use the plural snake-case collection: objects.purchase_orders:read and objects_purchase_orders_list. These names use the immutable collection slug, so changing display names does not change URLs or permissions. Create the definition and its Attributes before writing their values.

​
Create and update

Request bodies contain Attribute keys directly. Omitted Attributes remain unchanged during updates; null clears a value. All Attributes are optional, so an Object without Attributes can still have records. There is no required Name attribute.
Create returns HTTP 201; get, update, and archive return HTTP 200 with the same record shape:
Envelope fields are read-only. Unknown keys or invalid values reject the whole write. Saved values follow Attribute IDs internally: changing an Attribute key changes its public JSON key without losing values. Archived Attributes are omitted from reads. Archived select options remain readable on existing records but cannot be assigned again.

​
References

Reference Attributes point to one record of a chosen Object. Set the target Object when creating the Attribute in Manage, then write a record ID:
The value reads back as the same ID. The target must belong to the configured Object and the same workspace, and the caller must be able to read it. This works with platform targets such as Workers and workspace Objects alike. For example, assigning a Worker requires workers:read in addition to the source record’s write permissions. Archiving a target preserves existing links, but prevents new assignments. Omitting the Attribute preserves the link; null clears it. An unchanged Reference can be submitted again after its target is archived. API reads retain the stored ID; Manage only displays target labels and links when the caller can read the target. This release supports one-way, single-record References.

​
List and archive

Lists return data and, when there is another page, cursor. They accept the standard limit, cursor, starting_after, and ending_before parameters. count=true returns only {"total": 12} and cannot be combined with pagination. Lists include active records by default. Use archived=true to list archived records. Archived records remain available by ID; archiving retains their values and repeating the archive request has no effect. Archived records cannot be updated. Restoration is not yet available.

​
Tools

Tool discovery exposes five tools per visible workspace Object, for example objects_computers_create, objects_computers_get, objects_computers_list, objects_computers_update, and objects_computers_archive. Create and update take flat, typed Attribute arguments; get, update, and archive also take id. Tool schemas reflect the caller’s workspace and current Attributes.

​
Reference filters

List records with GET /v1/objects/computers?filter[assigned_to]=wr_example. Use an empty query value (filter[assigned_to]=) to match records without a link. The generated objects_computers_list tool accepts the same filter object, using JSON null for absence. Multiple fields are combined with AND. Filters apply before pagination and count=true. Active Reference, Number, Boolean, and Money Attributes support filtering. Use current Attribute keys; unknown keys, unsupported types, malformed values, and targets you cannot read are rejected. Archived readable targets can still be used to find existing links. Filtering does not change a link or authorize access to another Object. Table filters store Attribute IDs, so renaming a key preserves the table’s filter; API and tool callers must use the new key.

​
Numbers, booleans, and money

Number Attributes accept finite JSON numbers within ±9,007,199,254,740,991. They use JSON numeric precision, so use Money for exact currency amounts. Boolean Attributes accept true, false, or null; false and zero remain supplied values rather than being treated as unset. Money uses an amount in major units as a decimal string and a supported ISO currency code: {"amount": "1250.50", "currency": "USD"}. Values with more fractional precision than their currency supports are rejected, as are amounts outside the Number bounds. Negative and zero amounts are allowed. No exchange rate conversion occurs. Number and Money filters support eq, not_eq, gt, gteq, lt, and lteq. Boolean filters support eq and not_eq. A bare value means equality; use null with equality or inequality for unset or set values. For example:
For HTTP, encode nested filters as query parameters, such as filter[quantity][gteq]=2. Money comparisons require a currency and only match that currency. A currency-only filter is also supported: filter[purchase_price][currency]=USD. Currency filters also accept eq and not_eq, such as filter[purchase_price][currency][not_eq]=USD. Use sort=quantity for ascending order or sort=-quantity for descending. Sorting supports Number, Boolean, and Money Attributes; unset values come last in either direction, with record IDs breaking ties. Money sorts group by currency code first, then order amounts within each currency. Keep the same filters and sort when following a cursor.