Records

Records are the rows inside a table. The records API supports create, read, update, delete, and rich querying.

Create a record

POST /api/table/<table_id>/records/create

Request body

{
  "data": {
    "name": "Acme Corp",
    "email": "hello@acme.test",
    "status": "Active"
  }
}

Example

curl -X POST https://infolobby.com/api/table/101/records/create \
  -H "Authorization: Bearer il_live_..." \
  -H "Content-Type: application/json" \
  -d '{"data":{"name":"Acme Corp","email":"hello@acme.test","status":"Active"}}'

Response

The full record with the assigned ID.

Get a record

GET /api/table/<table_id>/record/<record_id>/get

Update a record

POST /api/table/<table_id>/record/<record_id>/update

Request body

{
  "data": {
    "status": "Archived"
  }
}

Only include fields you want to change.

Lookup fields accept either the related record ID or an object with id and title. For example, "user": 2 and "user": {"id": 2, "title": "Andreas"} are both valid.

Field value formats

• Select — a single select returns the chosen option as a string ("Active", or null when empty); a multiple select returns an array (["A","B"]). On write you may pass a single value, a one-item array, or a comma-separated string.
• User — returns { "id", "email", "name" } for a single user field (or null), and an array of those for a multiple user field. On write you may pass a user id, an email, an object with either, an array, or @me. Values must reference current workspace members. The email shown is always the member's current address, so it stays correct even after they change it.
• Lookup — single returns { "id", "title" } (or null); multiple returns an array of those.
• Date / Datetime / Time — values are returned and accepted in UTC, with no timezone conversion: date as YYYY-MM-DD, datetime as YYYY-MM-DD HH:MM:SS, time as HH:MM:SS. A date is a plain calendar date and is never shifted. The web grid displays these converted to the signed-in user's local timezone, so a value you write in UTC may look shifted in the browser — that is expected. See Dates, times, and timezones.

A single-valued field always returns one value (or null); a multi-valued field always returns an array ([] when empty).

Delete a record

POST /api/table/<table_id>/record/<record_id>/delete

Query records

POST /api/table/<table_id>/records/query

Request body

{
  "fields": ["name", "email", "status"],
  "where": {
    "status": "Active"
  },
  "order_by": "name",
  "order_dir": "A",
  "limit": 50,
  "offset": 0
}

Supported where forms:

• Simple equality: {"status": "Active"}
• Comparison: {"age": [">", 21]}

Or use the more verbose filters array:

{
  "filters": [
    {"column": "status", "compare": "=", "value": "Active"},
    {"column": "age",    "compare": ">", "value": 21}
  ]
}

compare accepts =, !=, <, <=, >, >=. field may be used instead of column. The following aliases are also accepted:

For IS_EMPTY and IS_NOT_EMPTY, the value field is ignored.

Combining filters with AND/OR

Each filter may carry an optional connector of "AND" (default) or "OR" that controls how it joins the filter before it. The first filter's connector is always treated as AND. Connectors are evaluated left to right with SQL precedence (AND binds tighter than OR).

{
  "filters": [
    {"column": "status", "compare": "=", "value": "Open"},
    {"column": "status", "compare": "=", "value": "Sent", "connector": "OR"}
  ]
}

This returns records where status is either Open or Sent. Omit connector entirely for the historical all-AND behaviour.

Query through a saved view

Pass view_id to query with the filters and sort saved on a table view. The view fully replaces request-supplied filters, where, order_by, and order_dir:

{
  "view_id": 42,
  "search": "acme",
  "limit": 100
}

Pass 0 for the table's synthesised Default view (unfiltered). search is still applied on top of the view's filters. See the Views API reference for the full view endpoints.

Internal layout renderers may pass append_filters: true with view_id to add range/layout filters on top of the saved view. Without that flag, the saved view remains authoritative.

Date tokens

These tokens resolve server-side and are valid only in query filters (where / filters). They are not accepted when creating or updating records — write an explicit UTC date there instead.

Date fields accept tokens that resolve server-side:

Example: all records created in the last 30 days:

{
  "filters": [
    {"column": "created", "compare": ">=", "value": "-30d"}
  ]
}

Current user token

User fields accept the literal @me, which resolves server-side to the authenticated user's email address. Useful in saved views so each viewer sees their own records without per-user filter duplication.

{
  "filters": [
    {"column": "assignee", "compare": "=", "value": "@me"}
  ]
}

For session and personal API-key requests, @me resolves to the logged-in user's email. For account API keys, it resolves to the account owner's email.

Search

{
  "search": "acme"
}

Batch delete

POST /api/table/<table_id>/records/delete_batch

{
  "record_ids": [1, 5, 12, 39]
}

File fields

File-type fields hold an array of attachment metadata objects. Reading a record returns the full array under each file field. Most callers should manage attachments through the dedicated Files API, which handles upload, append, delete, and download. Use this record/update endpoint with a {name, path, type, size, host} array only when you need to replace the entire attachment list of a field in one call.

When you set a file field this way you can also supply {url, ...} or {data, ...} source descriptors to pull a file from a URL or base64, and copying an attachment from another record makes an independent copy of the stored file. See File Attachments → Setting files by URL or base64 for the full item shapes and rules.