Test lookup-table requests

Open lookup-table operations

In Settings → Integrations, select a key and open Playground. Choose a lookup-table operation the key can use. For shared request, response, and code-sample controls, see API Playground.

Query rows

To query a table:

1. Choose Query rows and select a table under Build request.
2. Under Find rows by, choose a field and enter a value.
3. Use Add a condition to match another field. Both conditions must match.
4. Choose Send request.

Query conditions use equality. Each field can appear once, and conditions are combined with and. For example, a region condition and an owner-email condition return rows matching both values.

Expand Available fields to see field keys, labels, and types. Can filter marks fields ready for conditions. Field keys can differ from labels: Owner email might use owner_email in a request.

For List rows, Get row, and Query rows, Optional fields → Fields to return selects the response fields. Leave the selection empty to return every field the key can read. To change the key's permissions, use Overview → Edit access instead.

The Playground formats values for you. Enter a record reference as the Attio object ID and record ID separated by a slash; the request uses objectId and recordId. Dates use a date input. See Value formats when writing requests yourself.

Try a write

A key with lookup_tables:write permission also offers Add row, Update row, Add or update rows, and Delete row. Choose a custom table with test data before sending a write.

Send request applies the change to the actual table. Delete row sends immediately, without another confirmation. A sample response marked Example has not changed anything.

For an update, fill in the fields you want to change; omitted fields keep their values. For add-or-update requests, choose the lookup key and review each returned result. See Writing rows for empty values, version checks, and safe retries.

More filter options

Edit a copied sample in your application or API client to use:

• in, OR groups, or empty-cell filters.
• Pagination cursors and page sizes.
• Parallel segments.

The lookup-row query form does not offer every filter or pagination option. Use a copied code sample or your API client for these requests. To query lookup rows without a filter, send {} to Query rows from your API client.

This request finds rows in EMEA or AMER, or rows with no owner email. Replace the table ID and field keys with your own:

curl -X POST 'https://api.neondeerdata.com/v1/lookup-tables/3f6c2a9e-8b1d-4c7a-9e2f-5a1b7c4d8e90/rows/query' \
  -H "Authorization: Bearer $NEON_DEER_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "filter": {
      "or": [
        {"field": "region", "in": ["EMEA", "AMER"]},
        {"field": "owner_email", "eq": null}
      ]
    },
    "fields": ["account_domain", "owner_email", "region"],
    "limit": 100
  }'

Follow next_cursor until it is null, keeping the filter and segment settings unchanged. A short or empty page can still have another page. The data can change between requests.

Check a lookup-table integration

Test these responses with your application's API key:

• Compare a known match with the table in Neon Deer. Try a value with no match too; a valid query returns 200 and an empty data array.
• Check empty cells with eq: null. They are different from 0, false, and an empty string.
• Test a restricted key. An unavailable table returns 404, and unreadable fields cannot be returned or filtered.
• Read every page and handle errors and rate limits.

Read operations, including Query rows, do not change table data. Write operations apply real changes. After a write, read the affected rows back and inspect each item in an add-or-update response; a successful HTTP status does not mean every item succeeded.