Upsert rows into a table
Insert-or-update rows keyed on their business columns. Each row’s stable primary key (s_id) is derived from the key columns, so rows whose key already exists are updated in place and new keys are inserted — sending the same entity again is idempotent. key_columns is optional: omit it to use the table’s own declared business keys (the usual case), or pass it to override — an override must match the declared keys exactly unless the rows leave the declared key columns out entirely. Returns 200 when all succeed, 207 when some fail (see errors), and 422 when none do. Requires the tables:append scope.
Authorizations
The access token received from the authorization server in the OAuth 2.0 flow.
Path Parameters
Body
Upsert rows keyed on their business columns.
The primary key (s_id) is derived server-side from key_columns, so rows must NOT carry s_id; re-sending the same entity updates it in place rather than duplicating. Inherits the same per-row validation as append.
Rows to upsert, 1 to 500 per request. Each row is an object of column_name to scalar value; values are coerced to their column type by the table's schema. Every row must carry the same column names. Do NOT include the primary key (s_id) — it is derived from key_columns.
1 - 500 elementsBusiness-key column names that identify a row. The stable primary key (s_id) is derived deterministically from just these columns, so the same entity always maps to the same row: re-sending it updates in place. Each must be present and non-empty in every row. Omit to use the table's own declared business keys — the usual case, so a caller need not restate keys the table already defines. If provided, must not be empty, and must match the table's declared key columns exactly whenever the rows carry any of them: the declared keys are the row identity the backend enforces, so no other identity can upsert them idempotently.
1Response
Successful Response