Skip to main content
POST
Create record
This endpoint also creates versions. ROOTKey groups a record’s versions by the table’s primary key (the schema’s key column — by default the first field, e.g. id).
  • New primary-key value → new record.
  • Primary-key value that already exists → a new version of that record (a database-style update). The new version’s parentId is set to the existing entity’s root record automatically — you don’t send it.
So to update an entity, simply POST the same primary key again — there is no separate version-creation endpoint. Versioning is a built-in behaviour of this route, driven entirely by the primary key.See the Records overview → Versioning for the full model and how to read a record’s id back.

Authorizations

x-api-key
string
header
required

ROOTKey API key (rk_live_... for production, rk_test_... for the test network).

Body

application/json
ownerVault
string
required

Address of the table that will own the record. (ownerWallet is accepted as an alias.)

Example:

"0xdf67CA8286510997567685c0385ECeAb11C23C92"

recordData
object
required

The record's columns as a JSON object. Values are primitives (string, number, boolean, ISO date, null) or nested objects/arrays within limits: 1 MB per record, 64 KB per string, 100 properties, 10 levels of nesting, 1,000 array elements. Keys beginning with __ (and prototype-polluting keys) are stripped on ingest. The value of the schema's key column (the primary key) determines version grouping — see the endpoint description.

expirationDate
string<date-time>

Optional expiry date-time for the record.

Response

Record created (or a new version, if its primary key already existed)

Record create/version response. Note: unlike files, record creation does not return a transactionHash or the new record id — obtain the id from GET /platform/records (__meta.id).

chainId
number
required

Polygon chain ID (137 in production, 80002 on the Amoy testnet).

Example:

137