1. Get started
  2. Quickstart
  • Quickstart
  • Data Model
  • Errors
  • Webhook events — payloads, headers and signatures
  • API versions and changes
  • API changelog

Quickstart

Quickstart

Make your first authenticated call to the Corteksa CRM API in a few minutes. This works whether you're on the web or mobile app team, or an external partner integrating over the public API.

Before you start

You need two things:

  • A workspace — your Corteksa account. Every request is scoped to it.
  • An API key — create one in Settings → Developers → API keys. Keys look like crtk_live_<hex> and carry scopes (read.contacts, create.deals, …) that decide exactly what they can touch.

Your base URL depends on which kind of workspace you have. Look at the address you sign in at:

You sign in atYour workspace isBase URL
app.…Sharedhttps://app.corteksa.info/api/v1
your own name, e.g. acme.…Dedicatedhttps://acme.corteksa.info/api/v1

The API always lives on corteksa.info, not on the address you sign in at — sending an API call to the app's address returns a web page, not JSON.

  • Shared workspaces all use the same app.corteksa.info host. Your API key alone decides which workspace a request belongs to.
  • Dedicated workspaces have their own subdomain, which selects the workspace before the key is read — a key only works on its own subdomain.

Not sure which you have? GET /me returns "tenant_type": "hyper" for a shared workspace. Everything is versioned under /api/v1; see API versions and changes for what can change inside a version.

Step 1 — Make your first request

Read the records of any object (here, contacts). Send your key in the X-Api-Key header:

bash
curl https://app.corteksa.info/api/v1/object/data/contacts \  -H "X-Api-Key: crtk_live_7f3c…"

You get back the object's columns in data.fields, a page of records in data.data, and pagination at the top level (abridged):

json
{
  "status": 200,
  "message": "Object data retrieved successfully",
  "data": {
    "fields": [
      { "name": "name", "slug": "name-mp9nm29v", "label": "Name", "type": "text" },
      { "name": "email", "slug": "email-k2v8x1qa", "label": "Email", "type": "email" }
    ],
    "data": [
      {
        "name-mp9nm29v": "Sara Ali",
        "email-k2v8x1qa": "sara@example.com",
        "name": "Sara Ali",
        "slug": "9f2c4b7a1e03",
        "createdAt": "2026-09-14T10:00:00.000Z"
      }
    ]
  },
  "pagination": {
    "total": 1,
    "page": 1,
    "limit": 25,
    "totalPages": 1,
    "nextPage": null,
    "prevPage": null
  }
}

Each record is keyed by field slug. That's it — you're talking to the API. If you get 401, check the key; if you get 403, the key is missing the read.contacts scope.

Step 2 — Create a record

POST to the same object endpoint. The data object is keyed by each field's slug (not its display name). List an object's field slugs with GET /api/v1/object/field/active/contacts. A choice field, such as a select or status, takes the option id, or an array of ids when it holds many values:

bash
curl -X POST https://app.corteksa.info/api/v1/object/data/contacts \  -H "X-Api-Key: crtk_live_7f3c…" \  -H "Content-Type: application/json" \  -d '{    "data": {      "name-mp9nm29v": "Sara Ali",      "email-k2v8x1qa": "sara@example.com",      "stage-k2j9h4g7": "6a1f3c9e-2b7d-4e8a-9f0c-1d2e3f4a5b6c"    }  }'

The response is the new record, in the same shape as a record read (abridged):

json
{
  "status": 201,
  "message": "Data created successfully",
  "data": {
    "name-mp9nm29v": "Sara Ali",
    "email-k2v8x1qa": "sara@example.com",
    "stage-k2j9h4g7": [
      { "id": "6a1f3c9e-2b7d-4e8a-9f0c-1d2e3f4a5b6c", "value": "lead", "label": "Lead", "color": "#3B82F6", "icon": null }
    ],
    "name": "Sara Ali",
    "slug": "5c9696e92c84"
  }
}

Creating a record needs the create.contacts scope.

Step 3 — Keep in sync with webhooks

Instead of polling, subscribe to signed webhooks and Corteksa pushes record events (created, updated, deleted) to your endpoint. See the Receive webhooks recipe to register an endpoint and verify the signature.

Authentication at a glance

Different callers use different credentials — all over HTTPS:

CallerCredentialHeader
App users (web / mobile)JWT from loginAuthorization: Bearer <jwt>
External apps / partnersAPI keyX-Api-Key: crtk_live_<hex>
"Connect with Corteksa" appsOAuth tokenAuthorization: Bearer crtk_oauth_<hex>

External integrations start with an API key. When you want to act on another workspace's behalf, use the OAuth "Connect" flow. Both are covered in Connect with Corteksa.

Core concepts

  • Workspace — an isolated dataset. A shared workspace is reached on app; a dedicated workspace has its own subdomain.
  • Objects & fields — the CRM schema is dynamic. "Contact", "Company", and "Deal" are objects; each has typed fields, and you can define your own.
  • Records — the rows of an object. The records API (/api/v1/object/data/:objectSlug) is your main data surface.
  • Slugs, not IDs — everything is addressed by a slug (object_slug, record slug, and field slugs in the request body), never an internal numeric ID. Record slugs are opaque strings such as 5c9696e92c84; field slugs look like email-k2v8x1qa.

Next steps

  • API reference — every endpoint, interactive. Try a call and copy the request in your language.
  • Data model — objects, fields, and relations, and how the dynamic schema works.
  • API keys & scopes — the full auth model and the "Connect with Corteksa" OAuth flow.
  • API changelog — dated changes to the endpoints, fields, webhooks and authentication an integration uses.
  • Integration API Reference — the endpoints a key can reach, grouped by task, with the scope each one needs.
Data ModelNext >

Powered by heyo-docs

On this page

Before you startStep 1 — Make your first requestStep 2 — Create a recordStep 3 — Keep in sync with webhooksAuthentication at a glanceCore conceptsNext steps