Skip to content
Henceforth Docs

Read, update, and delete records through the API

Goal

Section titled “Goal”

Read a record by ID, apply a partial update to it, and delete it, through the Henceforth data API.

Prerequisites

Section titled “Prerequisites”

Steps

Section titled “Steps”

1. Read a record by ID

Section titled “1. Read a record by ID”

GET /data/core/Account/019502a4-b4e7-7f3a-8c1e-0a1b2c3d4e5f

Returns 200 OK with the record from the object’s compiled view, so the response contains system fields, user-defined fields, inherited fields (for derived objects), and cross-object formula values. If the record does not exist, this returns 404 with a RECORD_NOT_FOUND error.

2. Apply a partial update

Section titled “2. Apply a partial update”

PATCH /data/core/Account/019502a4-b4e7-7f3a-8c1e-0a1b2c3d4e5f

Only the fields present in the request body are modified:

{
  "industry": "Software"
}

200 OK returns the full updated record; updatedAt is refreshed automatically.

For inherited objects, the update is routed to the table that owns the field being modified — if the update touches fields from multiple levels of the inheritance chain, the service layer issues one UPDATE per affected table.

Required fields cannot be set to null. Formula and rollup fields cannot be included in the request body. Lookup field values are validated for UUID format and referential integrity. Immutable lookup fields (mutable: false) reject the update instead of applying it. See Relationships and Lookups for how lookup mutability is enforced.

3. Delete a record

Section titled “3. Delete a record”

DELETE /data/core/Account/019502a4-b4e7-7f3a-8c1e-0a1b2c3d4e5f

Returns 204 No Content with an empty body. For inherited objects, the FK cascade propagates the delete through the table chain. If the record is the target of a restrict lookup relationship and a child record still references it, the delete fails instead of succeeding. See Relationships and Lookups for how restrict / setNull / cascade behavior is configured and enforced.

Value Serialization

Section titled “Value Serialization”

Record responses (from reads, updates, and queries) serialize field values as follows:

Field type JSON representation
text JSON string
int JSON integer
decimal JSON string (to preserve precision)
bool JSON boolean
timestamp JSON string in RFC 3339 format with millisecond precision
date JSON string in ISO 8601 date format
json JSON object or array (as stored)
Lookup (UUID) JSON string or null
Rollup JSON integer or number (depending on returnType)

The durable home for this table is the generated field-type reference (#812); this is a compact copy for quick lookup while reading records back.

Verification

Section titled “Verification”
  • After the update, GET the same id and confirm the changed field(s) reflect your PATCH body and updatedAt has advanced.
  • After the delete, GET the same id and confirm it now returns 404 RECORD_NOT_FOUND.

See also

Section titled “See also”