Data Model

Corteksa's schema is dynamic. Unlike a fixed API, your workspace defines its own objects and fields at runtime — so the data model is a meta-model. Learn these four ideas and the whole API makes sense.

Objects

An object is a type of thing you track — Contact, Company, Deal, or anything you create. Some are system objects; most you define yourself. Each object has a stable slug (contacts, deals) used everywhere in the API.

Fields

Each object has typed fields. A field also has a slug (e.g. email-p0zx) — and this is the key you use in a record's data body, not the display name. There are 17 field types:

text · long_text · number · boolean · date · datetime · select · multi_select · rating · currency · email · link · phone · file · relation · smart_catalog · serial_number

select / multi_select values are validated against the field's allowed options.

Records

A record is one row of an object. The records API is your main data surface:

GET    /api/v1/object/data/:objectSlug            # list / search
POST   /api/v1/object/data/:objectSlug            # create
PUT    /api/v1/object/data/:objectSlug/:recordSlug # update

The data body is keyed by field slug:

{ "data": { "name-8fk2": "Sara Ali", "email-p0zx": "sara@acme.com", "status-a1b2": "Lead" } }

See the Quickstart for a full create example.

Relations

Objects link to each other through relations (one-to-one, one-to-many, many-to-many) — a Deal belongs to a Company, a Contact has many Deals. Relations are bidirectional and addressed by slug like everything else.

Slugs, not IDs

Every reference — object, record, field, relation — is a human-readable slug, never an internal numeric id. Slugs are stable across dev/staging/prod and safe to log or expose. This is a hard rule across the whole platform.

Where to look next

• Try the endpoints → API reference
• The internal entity specs (fields, relations, ERD) → Engineering › Internal Specs