Loading

API Overview

Every datastore you define gets REST endpoints. There is nothing to generate and no separate API project — the endpoints follow from the data model, the same way the forms and the audit trail do.

Where to find it

Architect Panel → Integration & Connections:

  • API Server — the console — settings, keys and the request log
  • OpenAPI Specification — the machine-readable description of what is exposed
  • API Clients — outbound connections, which are a different thing

Architect Panel → Activity:

  • Activity Log — what an API call changed

Inbound and outbound are different things

Worth settling immediately, because the vocabulary collides:

  • The API and API Server are inbound — other systems calling you. Callers authenticate with an API key.
  • API Clients are outbound — this platform calling somebody else's API.

They have separate configuration, separate logs and separate settings. If you are looking for the key a partner uses to reach you, it is not under API Clients.

The spec describes the running server

The OpenAPI specification is generated from the same module the API server uses to decide what a request may reach — one source, two callers.

That matters more than it sounds. A hand-maintained spec drifts from the server, and a spec that documents a path the server refuses — or omits one it serves — is worse than no spec at all. Here they cannot disagree, because they ask the same question of the same code.

Two gates decide what is reachable

A datastore must clear both:

  1. The system-table switch. Off by default, which blocks every one of the platform's own internal datastores.
  2. The sensitive list. Not switchable, ever. It stays blocked whatever the switch says.

The second is what makes the first safe to offer at all. Turning the switch on is a reasonable thing to want — it exposes reference data such as countries and currencies to an integration — but it is not a reasonable way to hand out password hashes, so the things that must never be reachable are not governed by a setting.

Permissions still apply

The API is not a way around your access rules. A key acts as an identity, and that identity's group permissions, field security and row-level access all apply exactly as they do in the interface.

This is why giving an integration its own identity with its own narrow permissions is worth the few minutes it takes: the API cannot see more than the identity behind it.

Everything is logged

Requests are recorded with the key, the datastore, the method, the outcome, how many rows came back and how long it took. That is what makes an integration diagnosable later, and it is on by default.

Start by reading the spec

Before writing any client code, look at the OpenAPI specification for the datastore you mean to use. It tells you what is exposed and in what shape — which is faster than inferring it from a successful call and safer than assuming.

Worked example

A partner needs read access to two datastores. They are given an identity in a group with read permission on exactly those two, an API key against that identity, and the OpenAPI spec. Nothing else in the system is reachable to them, and the request log shows precisely what they have called.

Recommendations

  • Give every integration its own identity with the narrowest permissions that work.
  • Read the spec before writing a client.
  • Leave the system-table switch off unless something specific needs it.
  • Keep inbound and outbound clear in your own notes — the names are confusing.