Overview

Publish any Base table you can access as a read-only HTTP endpoint — for scripts, spreadsheets, dashboards, or another system to pull data from, without giving that caller a Tellzm login. You choose exactly which fields are returned and which of those are filterable; every other field is never reachable through the endpoint, no matter what the caller sends.

Publishing an endpoint

From a Base table's APIs tab (or Manage → Data Table APIs), create a new endpoint:

1. Pick the fields the endpoint may ever return (exposed fields).
2. Pick which of those fields callers may filter on (queryable fields — always a subset of exposed).
3. Optionally add a row filter to further scope which records are ever returned (e.g. only records where status = "published").
4. Choose an access mode: public or authenticated (below).

Any endpoint on a table is visible to anyone who can access that table in Tellzm, regardless of who created it — visibility follows table access.

Public vs. authenticated access

Public endpoints have no credential at all: anyone with the endpoint's URL can read the exposed fields. Because this is genuinely open, publishing (or switching to) public requires you to explicitly confirm "anyone with the link can read the configured fields" before the endpoint goes live.

Authenticated endpoints require a bearer API key:

Authorization: Bearer dtk_xxxxxxxxxxxxxxxxxxxx

The key is shown once, at issue or rotation time — Tellzm only ever stores a hash of it, never the plaintext, so if you lose it you rotate rather than retrieve.

Both modes are reachable at:

https://api.tellzm.com/data-apis/<endpoint-token>/records
https://api.tellzm.com/data-apis/<endpoint-token>/records/<record-id>

An endpoint that's disabled, revoked, or whose backing table is gone always responds 404 — the response never distinguishes why, so a caller can't probe for which case applies.

Query syntax

All parameters are optional and combine on the list endpoint (GET .../records):

Example:

GET /data-apis/abc123/records?get[city=Cairo]&return=[name,email]&limit=25

{
  "data": [
    { "id": "rec_1", "name": "Amer", "email": "[email protected]" }
  ],
  "nextCursor": null,
  "count": 1
}

A single record, fully projected to the exposed-field allowlist:

GET /data-apis/abc123/records/rec_1

Fetching a record outside the endpoint's row filter behaves exactly like a record that doesn't exist — 404.

A malformed query (e.g. an unclosed get[) returns 400.

Writing data (create, update, delete)

An endpoint can also accept writes — creating, updating, and deleting records — when its creator enables them. Writing is configured separately from reading: the creator chooses which operations are allowed (create / update / delete, any subset) and a writable-field allowlist (the fields an external caller may set), independently of the read fields. A field that isn't in the writable allowlist can never be written, no matter what a caller sends.

Authentication. Authenticated endpoints require the API key on every write (Authorization: Bearer <key>). Public endpoints are read-only by default; a creator must give a separate confirmation to allow anonymous writes, which are then rate-limited more strictly than authenticated ones.

Create — POST /data-apis/<token>/records with a JSON object of field values (referenced by field name):

POST /data-apis/abc123/records
Authorization: Bearer dtk_live_...
Content-Type: application/json

{ "name": "Ann", "status": "open" }
→ 201 { "data": { "id": "rec_42" } }

• A field not in the writable allowlist → 400 (the whole request is rejected; nothing is written).
• A missing required field, or a value that doesn't match the field's type → 400.

Update — PATCH /data-apis/<token>/records/<recordId> with the fields to change (writable fields only):

PATCH /data-apis/abc123/records/rec_42
{ "status": "closed" }
→ 200 { "data": { "id": "rec_42" } }

Delete — DELETE /data-apis/<token>/records/<recordId>:

DELETE /data-apis/abc123/records/rec_42
→ 200 { "data": { "id": "rec_42", "deleted": true } }

Deletes are soft (recoverable). Update and delete can only reach records within the endpoint's row filter — a record outside that scope (or one that doesn't exist) behaves identically: 404. Records created through the API are marked as API-originated, so they're distinguishable from records a member entered by hand.

Rate limits

Every request is rate-limited per endpoint and per caller IP, with a stricter budget on public endpoints than on authenticated ones — a credentialed, revocable caller gets a larger allowance than an anonymous one. Exceeding the limit returns 429. Writes have their own, tighter budget than reads, and anonymous writes are the most restricted of all.

Credential rotation

For an authenticated endpoint, rotate its API key any time from the endpoint's settings — this issues a new key (shown once) and immediately invalidates the previous one. Revoking removes the key outright. Neither action requires downtime on your side beyond updating whichever system holds the old key.

When access changes

If the endpoint's creator loses access to the underlying table (e.g. they leave the workspace or lose table permission), the endpoint is disabled automatically rather than left live or silently deleted — a workspace admin or another accessor of the table can re-own or remove it. If the table itself is deleted, the endpoint's URLs resolve to 404.