Skip to main content
A family is one named dataset that Records can read, such as one table of a system of record’s warehouse replica. Families are grouped into planes, and each plane is one registered source area with a stable key. The generic family read, GET /api/v1/records/families/{plane}/{family}, reads any registered family by those two names. It is the core contract of Records: its behavior is the same for every family, and the family’s own registration decides the columns and the row bounds. What a plane and a family are, and why the set is a registry, is on the Records overview.

How it works

  1. Nexio resolves the person’s authority, as for every read (Authority and scope).
  2. Nexio looks up {plane}/{family} in the registry. An unregistered pair answers 404 not_found.
  3. The family’s serve grain decides which key filter the read accepts and how rows are bounded to the person (Serve grains).
  4. Nexio reads the family’s declared columns from your warehouse at request time, one page at a time.
  5. The response carries the column names once and each row as a list of values in that order, with the serving, family_serving and scope blocks.

What a family declares

The response is columnar rather than one object per row because the row shape belongs to the registration, not to a per-family type: a family registered in a later release serves through the same route with no client change beyond reading its columns.

Serve grains

Every family declares one of four grains. The grain names policy and client are the two keyed record kinds: a client is a top-level record and a policy is a record under it. A key filter the grain does not take answers 400 invalid_request, and so does a malformed key. When a person’s scope admits no rows at all, the read answers 200 with an empty page.

The positional rule

Some columns identify a person directly. Where such a column is served depends on the position of the read:
  • On a policy or client family read without a key filter, the column is present and every value is null.
  • On a read narrowed by policy_key or client_key to a record the person may open, the column is served.
  • On a table or org family, the column is not served at all: it is left out of columns, because those grains take no key that could narrow the read.
So a column that is null on a broad read and filled on a keyed read is expected. The broad read is not incomplete. Field classes, such as compensation fields, are withheld on every read by the person’s policy instead; see Field classes.

Keys

Keys are opaque strings. Read them from a row, a register or a keyed read, and send them back unchanged; never build or parse them. A key filter never widens the read: the person’s scope bounds the rows first, and the key narrows inside it.

Read a family

The example below reads a reference table, so it takes no key filter.
200 OK

Pagination and cursors

The family read pages by keyset: each page continues after the last row the previous page returned.
  • Follow page.next_cursor until it is null. An empty data array with a null cursor is a complete, empty answer.
  • The cursor is opaque. It fixes the family and the key filter of the first page. Send cursor, an optional limit, connection_id and the identity headers on each next page; sending policy_key or client_key with a cursor answers 400 cursor_filter_mismatch.
  • A cursor from another family, or one that is malformed, answers 400 invalid_cursor. A cursor that no longer matches how the family is served answers 409 cursor_expired: start again from the first page.
  • Each page is a new current read. A row created or changed during a walk can appear on a later page, or be missed. When the data changes during a walk applies here too.

Composite reads and dedicated routes

The generic read serves one family per call. Dedicated routes can exist beside it for a connected system type: registers, keyed reads of one record and its sub-resources, composite reads that compose many families under one authority in one call, and document content, which fetches a file from the system of record’s own API. A composite read reports an outcome for each family it composes, in the same terms as a single family read (presence, plus coverage and a reason); the model is on Completeness and errors. A dedicated route that serves one family returns its plane in family.plane; the generic read returns it in plane.

The registry today

Every plane registered today belongs to one supported system type, AMS360, replicated to Snowflake. Three of its families are served only through dedicated reads, so the generic read reaches 100 of the 103; reading one of the three here answers 404 not_found.

Errors

Authority refusals (identity_unmapped, scope_unavailable and the rest) are on Authority and scope.

Next

Read a family

Endpoint reference.

Completeness and errors

Tell every outcome apart.

Authority and scope

How the person’s rows are bounded.

Registers and pagination

Register paging and totals.
Last modified on September 25, 2026