Derive what one destination record type can do
The legal write actions (including composite create-or-update), the fields records can be matched on, the supported write modes, and whether matching is possible at all — everything the export editor’s action, match-key and write-mode controls are driven by.
Probes the LIVE connection, so expired credentials fail here with a message about the connection rather than at run time.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Response
Successful Response
What one destination record type can actually do, fully derived.
The write actions this record type supports, including composite upsert.
What one export cell does at the destination.
Its own vocabulary, not a copy of the integration stratum's
WriteBehavior: the members and their values differ, and
table_export_integration translates between the two at the seam
(_WRITE_BEHAVIOR_TO_EXPORT_ACTION). Mirroring has no member here
because it deletes and recreates the whole destination object, which is a
whole-object concern rather than a per-row one.
create, update, upsert Action values with a synchronous bulk write method — the ones a batched export can actually use.
Whether an existing record can be found by field value — the precondition for replay-safe creates. False means only blind creates are possible and the editor must say so.
Selectable match/identity fields per action value. An EMPTY list means the destination resolves identity dynamically (a database: any column), and the picker falls back to the discovered fields.
The destination's own recommended batch size, or None.
Whether records can be written in batches.
Supported write modes — replace, patch, set_once — for update/upsert.