Choosing What to Expose

Exposure is a deliberate choice per datastore. Nothing is exposed because it exists.

Where to find it

Architect Panel → Integration & Connections:

• API Server — which datastores are exposed
• API Clients — per-client credentials and rights

Start from the use case

Expose what a specific consumer needs for a specific purpose, rather than exposing broadly in case something is useful. A wide API is a wide surface, and every field on it is a field somebody may come to depend on.

Permissions still apply

The API enforces the same permission model as the interface. A client sees what its credentials allow, and exposure does not bypass row-level or field-level rules. Exposing a datastore is not the same as making its contents public.

Some prefixes are never exposed

Certain internal subsystems are excluded from exposure by design — messaging is one, because those tables carry message content and recipient identity. That exclusion is not configurable, and it is deliberate.

Fields deserve the same thought

A datastore worth exposing may contain fields that are not. Notes fields are the usual culprit: free text written by staff for internal purposes, which nobody was writing with an external audience in mind.

Review it periodically

Exposure decisions get made for a project and then persist. Once a year, look at what is exposed and to whom, and remove what nothing is using. An unused exposed datastore is risk without benefit.