Choosing What to Expose

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

Where to find it

Architect Panel → Integration & Connections:

• API Server — which datastores are exposed, and the API settings
• API Clients — per-client credentials and their rights

Start from the use case, not the schema

Expose what a specific consumer needs for a specific purpose. Exposing broadly "in case something is useful" produces a wide surface, and every field on it is a field somebody may come to depend on — which then makes it hard to change.

The narrower the exposure, the more freedom you keep to restructure your own data later.

Permissions still apply

The API enforces the same permission model as the interface. A client sees what its credentials allow, and row-level and field-level rules apply exactly as they do for a person.

Exposing a datastore is not the same as making its contents public — but it is the step that makes a permissions mistake reachable from outside, so it is worth re-checking the permissions on anything you expose.

Some subsystems can never be exposed

Certain internal areas are excluded from exposure by design and the exclusion is not configurable. Messaging is the clearest example: those tables carry message content, recipient identity and delivery detail, and there is no version of exposing them through a generic API that is a good idea.

If you find you cannot expose something, that is usually why, and the answer is to build a purpose-shaped endpoint rather than to look for a way round it.

Fields deserve the same thought as datastores

A datastore worth exposing may contain fields that are not. Internal notes are the usual culprit — free text written by staff for colleagues, in a tone and with a candour nobody chose with an external audience in mind.

Review the field list, not just the datastore list, before enabling anything.

One client, one purpose

Issue a client per consumer and per purpose in API Clients. Shared credentials cannot be revoked without collateral damage, and their call logs cannot tell you who did what.

Worked example

A housing association exposes a repairs datastore to its contractor's system. Three fields are excluded: the internal notes, the vulnerability flag, and the officer's mobile number. The contractor gets what it needs to schedule work and nothing it does not, and the exclusion decisions are recorded so the next person to look does not simply re-enable them.

Review it periodically

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

Recommendations

• Expose the minimum, and review the field list too.
• Re-check permissions on anything you expose — exposure makes mistakes reachable.
• One client per consumer.
• Annual review, and revoke what is dormant.