v2's one row-write endpoint; there is no bare per-row insert (an insert-only call is just an upsert whose rows match nothing). All writes go through api_batches and are idempotent per batchId.

Rows matching an existing row on every matchColumns value update that row's input cells; non-matching rows insert. Per-row inserted/updated/skipped outcomes are recorded on the batch.

• Row keys and matchColumns are input column slugs (from GET /tables/{tableId}/columns → columns[].slug), never display names. A non-slug row key → UNKNOWN_FIELDS.
• matchColumns (required) must be real input columns (UNKNOWN_COLUMN) and every match value must be present + non-empty on every row (MISSING_MATCH_VALUE).
• Duplicate request keys → DUPLICATE_MATCH_KEY; multiple existing rows match one key → AMBIGUOUS_MATCH (409).
• enrich (default true) enriches freshly inserted rows.
• reenrichUpdated (default false): set true to also re-run enrichment on rows the upsert updated (re-spends credits); off by default so an upsert never silently re-enriches matched rows.

Only input-kind columns are writable. Enrichment, score, and sequence columns are populated automatically; sequences are agent/column-generated only (see POST /tables/{tableId}/campaigns), never set via this endpoint; passing one returns NON_INPUT_COLUMNS.

The response references the tracking object by id: it is an enrichment_run the caller polls via GET /enrichment-runs/{runId}.