Your Airtable schema, explained

Your schema is the structure of your base — every table, every field, every field type, and every select option — separate from the records stored inside it. It is the part that everything else depends on, and the part almost nobody versions.

See yours in 30 seconds. Paste a schema export into the free inspector for a structural health report — or paste two and get a diff.

Open the Schema Inspector

What the schema actually contains

Tables — with stable IDs that survive renames.
Fields — name, stable field ID, and type.
Field options — single/multi-select choices, number precision, date formats, linked-record targets.
Views — the saved filters and configurations built on top of the fields.

The stable IDs matter more than they look. Names change constantly; IDs do not. Any tool that tracks schema by name will report a rename as a delete plus an add, which is noisy and wrong. Tracking by ID lets a rename be reported as what it is.

How to export it

Airtable exposes base structure through its Meta API — the schema.bases:read scope returns tables, fields, types, and options as JSON, without touching record values. That JSON is your schema export, and it is what the inspector on this site reads. You can also fetch it yourself with a personal access token if you would rather script it.

Why version it

A schema export is a point-in-time photograph. On its own it tells you what the base looks like today. Its value comes from having yesterday’s too, because the interesting question is never “what is the structure?” — it is “what changed, when, and does it break anything?”

Structural changes that reliably break downstream tooling: a field type conversion that discards data (single-select to text drops the option set), a deleted field that a Zapier step still maps to, a removed select option that a filtered view depends on, and a renamed field that an integration matched by name. None of these raise an error inside Airtable. They surface later, somewhere else.

Documenting a base for other people

The same export doubles as documentation. A readable map of every table and field is genuinely useful for onboarding someone new, handing a base to a client, or auditing what a base has grown into after two years of ad-hoc additions. The inspector produces that view from a paste, with nothing stored.

Track it automatically. SchemaWard snapshots your base structure on a schedule, diffs each snapshot against the last, and alerts you when a change is the breaking kind. Zero-PII — it reads schema definitions only, never records.