Create the table and start loading its rows
Create the table and its columns from the reviewed mapping, then start the row load in the background.
The table exists as soon as this returns, so the client can navigate to it immediately and watch rows arrive. Poll the job to follow progress.
Committing twice is refused — the second call finds the import already running rather than creating a second table.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Body
Request body for committing an upload.
Send the mapping the user reviewed. Omitting a field's entry leaves that column out of the table entirely, which is how a user drops a column they do not want.
The reviewed mapping, in display order.
1 - 500 elementsName for the table this creates.
1 - 255How many of the file's data rows to write, counted from the top. Clamped by the plan's own ceiling, so this can only ever import less than the preview's importable_row_count, never more. Omit for every row the plan allows. Named for the user's choice, unlike the preview's row_limit, which is the plan's cap.
x >= 0Response
Successful Response
A CSV import's current state.
Poll this until status is terminal. imported_rows climbs as the load
runs, so it doubles as a progress bar against total_rows.
The mapping in force.
Why the whole job failed, if it did.
Rows that could not be written — the exact count.
Rows written so far.
A capped sample of per-row failures; failed_rows carries the full count.
Where a CSV import has got to.
PENDING is a parsed-and-stored upload the user has not committed yet —
it holds an inferred mapping and nothing else. RUNNING means the table
and its columns exist and the row job is inserting. The two terminal states
are absorbing: a job never leaves them.
pending, running, succeeded, failed The table this created; null before commit.
Rows this import will write: the file's rows, capped by the plan and by whatever max_rows the commit asked for.