Update Schema
update_schemaReplace a project's WHOLE schema (saves to database, does NOT deploy). DESTRUCTIVE: a table or field the schema leaves out is dropped by the next deploy.
For a new data model or a template. To change part of a schema use patch_schema, and drop_schema_items to drop; sending back a large schema to change one field risks changing something else on the way.
⚠️ Follow ALL rules from create_project: • FLAT format (no 'fields' nesting) • string: max_length (default 255) • decimal: precision + scale (default 10, 2) • Use "datetime" NOT "timestamp" • DON'T define: id, created_at, updated_at, row_version • NEVER create users/customers/employees tables (use app_users)
⚠️ MIGRATION RULES: • New fields MUST be "required": false OR have "default" value • Cannot add required field without default to existing tables
WORKFLOW:
get_schema to see the current schema (its 'version' pins the save)
preview_schema_change with the new schema: check 'diff' and 'plan'
update_schema (pass expected_version to be refused if someone else saved meanwhile)
deploy_staging, then get_job_status
A schema the deploy would refuse is refused here, and nothing is saved. The answer carries 'diff', 'plan' and the new 'version'.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | New JSON schema in FLAT format (table_name → field_name → properties) — the WHOLE schema. Every field MUST have a 'type' property. | |
| project_id | Yes | Project ID (UUID) | |
| expected_version | No | The 'version' a get_schema read answered. The save is refused (409) when the saved schema changed since, so two editors never overwrite each other silently. |