Understand objects, properties, records, and relations

Model your data before building an integration. In this example, a candidate applies for a vacancy; Caraer stores each entity once and links them together.

The four building blocks

Concept	Meaning	Example
Object	The schema for a kind of record	candidate, vacancy
Property	A reusable field definition	email, firstname
Record	One entity and its property values	A particular candidate
Relation	A named connection between entities	applied_for

You need schema read access to inspect objects. Changing a schema requires its write permissions. Record permissions are separate from schema permissions.

Start with one record

Once the candidate object has an email property, its record values look like:

{ "properties": { "email": "alex@example.com" } }

Create it with the record guide. To attach that candidate to a vacancy, use the schema’s relation name and the two record UUIDs, following record relationships.

Reuse fields intentionally

Properties with the same internal name share a definition across objects. Changing a shared label, validation rule, or select option affects every object using that property. Layout settings such as group and hidden are per object. See shared properties before editing a reused field.

Give one entity multiple contexts

If the same person is both a contact and candidate, extended objects let one UUID and one value set appear in both object contexts. Extending does not copy the record or change its primary object.

Common mistakes

• Treating an object as a single record rather than a schema.
• Reusing a property name for two fields with different meanings.
• Assuming a record’s presence in another object grants access to it.
• Adding indexes without a query that needs them.

Keep internal names stable. Verify the live schema and API reference before constructing a payload.