Schema & Fields

A Data Feed turns a raw HTTP response into a table of records that Studio apps can query. The mapping is controlled by three sections inside the Data Request: Data Path, ID Path, and Capture Variables.

Data Path

The JSON path to the array of records inside the response. For an API that returns this:

{
  "items": [
    { "id": "abc", "name": "..." },
    { "id": "def", "name": "..." }
  ],
  "next_cursor": "xyz"
}

The Data Path would be items — that’s the array Composer should iterate. For an API that returns a raw array at the root:

[
  { "id": "abc", "name": "..." },
  { "id": "def", "name": "..." }
]

The Data Path is $ (the JSON root). Composer infers the Data Path on first run and lets you correct it if needed.

ID Path

The JSON path to a unique identifier on each record. Used to deduplicate across runs and as the join key for Detail Requests. For records like:

{ "id": "abc-123", "name": "...", "owner": { "id": "user-1" } }

The ID Path is typically id. If you need to drill into an object, use dotted notation: owner.id. If a record has no natural primary key (rare), Composer can synthesise one — e.g. by hashing a stable subset of fields. Tell it the rule in plain English.

Capture Variables

Pull values out of the primary response so the Detail Request can use them. By default, Composer captures the ID (so Detail Request URLs can use {{id}}). You can capture additional fields — useful when:

Detail Request needs a non-ID identifier (e.g. a slug or external_ref)
Detail Request needs context the API doesn’t echo back (e.g. the workspace ID from the list response)

The Capture Variables section is added via the + chips below the URL row in the Data Request:

+ Capture Variables
  └─ Variable name: slug
     JSON path: $.slug

Then in the Detail Request URL: https://api.example.com/items/{{slug}}/full.

Inferred schema

Composer reads the response and infers field types — strings, numbers, booleans, ISO-8601 dates, arrays, and nested objects. If a field is sometimes null it is marked nullable.

Refining the schema via Composer

If the inferred schema is wrong (e.g. a numeric ID was inferred as a string), tell Composer:

"Treat the `external_id` field as a string, not a number.
 The remote API sometimes returns it with a leading zero
 that we don't want to lose."

"Map the `created_at` ISO 8601 string to a proper datetime
 type so Studio can do date arithmetic on it."

"The `tags` field is sometimes a comma-separated string
 and sometimes an array. Always treat it as an array,
 splitting on comma when needed."

Composer adds a transformation step to the feed without affecting the source.

Schema in Studio

Inside a Studio app, ask Composer to list available fields:

"Show me what fields are available on the GitHub Repos feed."

It’ll print the schema as a table. Field names are stable across Feed runs as long as the source’s API contract doesn’t change.

Privacy: The Studio Composer only sees field names and types — never field values. See Security & Privacy.

Versioning when the source changes

When a source’s API contract changes (e.g. a vendor renames device_name to hostname):

The next Feed run picks up the new field
Existing Studio apps querying the old name will return empty for that field
Composer can rename the field on the Feed side (hostname → device_name) so apps don’t break — ask it explicitly

The audit trail of schema changes is in Settings → Logs → Audit Log.

Get started

Core Concepts

Build

Reference

Settings

Trust & Security

Data Path

ID Path

Capture Variables

Inferred schema

Refining the schema via Composer

Schema in Studio

Versioning when the source changes