Change a database directly
Structural changes belong on the development database. Pass environment: "development" and reshape it as freely as you like — it holds no customer data, so there is no gate and nothing to approve. Deploying compares the two databases and applies the difference to production as one change; nobody names or numbers it.
Structural SQL aimed at production is refused (structural_change_needs_schema): production’s shape moves only by deploying. What production accepts here is data — seeding rows, correcting a value, a backfill — recorded under the filename you choose, checksummed so an edited migration can’t silently fail to land.
A Time Travel restore point is captured before anything runs and returned as bookmark. Statements that destroy data are refused unless allow_destructive is true, and only when the target actually holds rows.
Authorizations
API key in the format: Bearer {api_token}
Headers
Makes this write safe to retry: a repeat with the same key replays the first response instead of creating a second resource. Scoped to the account, remembered for 24 hours; reusing a key with a different payload is an error.
255Path Parameters
The resource ID (e.g., "prod_abc123") or slug (e.g., "my-product")
Body
Unique migration name, e.g. 0003_add_ratings. Used as the idempotency key in the ledger.
The migration SQL. Multiple statements may be separated by ;. Runs in one batch with the ledger insert, so a failed migration is never recorded as applied.
Set to true to permit data-destroying statements (DROP/TRUNCATE/unqualified DELETE|UPDATE) against tables that hold rows. Defaults to false.
Which database to change. development is the one you build against — created on first use, and where every structural change belongs. production is the live site's, and accepts data changes only. Defaults to production.
development, production Response
Migration result
The statements that were classified as destructive, each with the table it targets and that table's row_count.
Statements that keep every row but can still fail against existing data or break the currently live version of the site (column renames, NOT NULL without DEFAULT, UNIQUE indexes). Reported, never blocked.
SHA-256 of the migration SQL, recorded in the ledger to detect later edits to the file.

