Skip to main content
A schema defines the columns that Lasso extracts from your source data. Think of it as a blueprint for your table.

Column definitions

Each column has a key, label, and type:
  • key — Machine-readable identifier (snake_case). Used to access data in rows.
  • label — Human-readable name shown in exports and the dashboard.
  • type — The data type Lasso should extract. See below.
  • required — Whether this column must have a value for every row.

Shared Attributes and helpers

Schema and table reads return attribute_id and kind for every column:
  • kind: "attribute" identifies a canonical Shared Attribute. attribute_id is its stable UUID.
  • kind: "helper" identifies a schema- or table-local helper. Its attribute_id is null.
Catalog and persistent or scheduled sync destinations accept canonical Attribute-backed columns only. Filter for kind == "attribute"; API visibility alone does not make a helper eligible. For compatibility, schema create and update requests can omit both identity fields. The server creates or attaches the Shared Attribute for the supplied key. Send kind: "helper" to create a local helper, or send an existing attribute_id with kind: "attribute" to attach that Attribute. Retain the server-issued column id when you round-trip a complete schema update.

Column types

Auto-generated schemas

If you are not sure what columns to define, you can let the AI generate a schema from sample data:
The AI analyzes your sample and infers appropriate column keys, labels, and types.

Reusing schemas

Schemas are reusable across multiple tables. Create a schema once, then reference it by ID when creating new tables. Existing tables use a forked schema snapshot and retain their original column definitions when the source schema changes. Permanent deletion succeeds only when the schema has no extraction tables, Catalog products, mappings, views, templates, feeds, Shopify links, or Relation Attribute references. A dependency conflict returns 409 without changing those resources.