API Maker
The backend engine for the AI era
Operations
Copy a table, a database or a whole instance anywhere, and choose what each table becomes before it goes in.
Export from the admin panel with the database's own program, mongodump, pg_dump, mysqldump, SqlPackage or Data Pump, in the version which suits its server. The file describes every table it holds, so an import first sets it beside the database it goes into: you see what is new, what changed and what is there only now, and choose, table by table.
Step through it, slow it down, or open the full canvas.
api-maker/features/import-exportLiveThe database's own program, in the right version. Export from the ⋮ menu of a database. The server of shop says PostgreSQL 16.4, so the job runs pg_dump 16: installed from its publisher the first time a server needs it, unless an admin chose a version.
Export from the ⋮ menu of a database. The server of shop says PostgreSQL 16.4, so the job runs pg_dump 16: installed from its publisher the first time a server needs it, unless an admin chose a version.
A .zip with the dump, a README which says how to restore it by hand, and manifest.json: the version, the program, and every table with its rows, columns and indexes. Each entry has its SHA-256.
The download is a link of 15 minutes: the browser takes the file itself, gigabytes included. Or send it to a storage of Automatic Backup, beside the backups.
Imported into staging, each table of the file is set beside the table there: orders changed (12 rows more in the file), items new, customers the same, coupons there only now.
Merge the orders (the 12 rows the database lacks are added), make the items, keep the rest. After the import, every table is counted: its rows now beside the rows of the file.
pg_dump of the major version of the server, the 8.4 client for MySQL 8, mariadb-dump of the line of the server: installed from the publisher the first time a server needs it, checked against its checksum. Or choose one version.
One .zip with the files of the program, a manifest with every table, its rows, columns and indexes, the SHA-256 of each entry, and a README which says how to restore it by hand.
Each table of the file beside the table there now: new, changed with the difference of its rows, columns and indexes, the same, or there now only.
Replace a table, merge the rows it lacks, keep it, or remove one the file does not have. What removes rows asks for the name of the database first, and every table is counted after.
A download is a link of 15 minutes the browser follows itself. A file you send goes in pieces of 4 MB, a piece which fails sent again, up to 64 GB. An export can also go to a storage of S3.
A job can run at the least priority of the server: its programs take what the APIs leave. Two jobs run at a time on each server, the others wait in turn.
A developer exports production, imports it into staging and sees what differs: the orders changed, the items are new, a table of a test is there only now. The orders are merged, the items made, the test table kept: staging has the data of production without losing its own.
shop_pg-shop-20261031-012233.zip├── manifest.json the database, its version, the program, every table : rows, columns, indexes├── README.txt how to restore it by hand : pg_restore --dbname=… shop.dump└── shop.dump the file of pg_dump, in its own formatYes. The file holds what the database's own program wrote, and its README says the command which restores it.
The one most compatible with the server of the database, unless an admin chose a version on Sandbox Settings. A server which lacks it installs it from the publisher, checked against the checksum.
No. Table by table, only the tables you replace, merge or remove change; the others stay as they are.
Documentation