key (lowercase letters, digits, and underscores), a name (display label), a type, and optional constraints. Field values in a record are keyed by the field’s key.
Types
This table is generated from the platform’s field-type definition, so it lists exactly the types the API accepts.
Validation and constraints
A record write checks each value against its field’s type and constraints. A failing value is rejected with422 VALIDATION_FAILED, reported under the field’s key in error.details. Keys that are not declared fields are dropped. Sending null for a field clears it.
References
Areference value must name a record that exists in the referenced entity, in the same project, and in the same environment — a production record can reference only production records, and a sandbox record only records in its own sandbox. The check runs when the value is written. If the referenced record is deleted later, the value is kept; resolve it with a read and treat 404 as “no longer exists”. An update that resends a reference unchanged is not re-checked, so a record whose target was deleted can still be edited. To load the referenced record, call sdk.getRecord(referencedEntitySlug, value).
Indexing
A field of a bounded type (number, currency, date, boolean, enum, reference, email, phone) can be declared indexed: true so filters and sorts on it are served by a database index — at most 10 per entity and 50 per organization, with string values limited to 255 characters. See Indexing fields.
Filtering by type
Which filter operators a field supports depends on its type:System fields
Every record also carries these read-only fields — never include them in create or update payloads:Naming conventions
- Field keys:
snake_case—due_date,is_complete,contact_email - Field names: Title Case — “Due Date”, “Completed”, “Contact Email”
- Entity slugs: lowercase, hyphenated, plural —
tasks,contacts,inventory-items(derived from the entity name)