What Is Reachable
Not every datastore is reachable over the API. Two gates decide, and only one of them is a setting.
Where to find it
Architect Panel → Integration & Connections:
- OpenAPI Specification — the authoritative list of what is exposed
- API Server — the settings, including the system-table switch
Architect Panel → Data:
- Datastores — the datastores themselves
Gate one: the system-table switch
The platform's own internal datastores are distinguishable from yours. With the switch off — the default — none of them is reachable at all.
Turning it on is a legitimate thing to want: it makes reference data such as countries, currencies, languages and icons available to an integration, along with some reporting metadata. Turn it on for that, not as a general loosening.
Gate two: the sensitive list
A hardcoded set that stays blocked whatever the switch says. It is not configurable, and that is deliberate — it is the reason the switch is safe enough to offer.
What it protects, and why each one matters:
- Credentials and tokens — API keys themselves, OAuth access and refresh tokens and their signing keys, SCIM bearer tokens, passkeys, and two-factor seeds. A TOTP seed is password-equivalent.
- User records — password hashes, reset tokens, sign-in links, and live sessions.
- External system credentials — database hostnames and passwords, data source credentials for every driver, Azure, Google and Xero client secrets, accounting feed tokens, EDI certificates and private keys, deployment targets.
- Financial instructions — bank mandates, where a reference is an instruction to collect money.
- Your defences — blocked addresses and accounts, which map what you are protected against; which sign-in methods exist; directory topology.
- Execution surfaces — custom PHP callbacks, the extension registry, and the task scheduler, which runs whatever it is told to.
Two of those are worth dwelling on
The block list is readable data, not credentials — and it is still blocked, because a list of what you block tells an attacker what you have noticed.
The scheduler is blocked because it is not data at all: it is a list of things the platform will execute. Write access there is remote code execution with extra steps.
Check what an integration can actually see
Do not reason about it from the gates — read the OpenAPI specification as that key. It is generated from the same logic the server enforces, so it is the honest answer, and it takes a moment.
Permissions narrow it further
Clearing both gates makes a datastore reachable in principle. Whether a particular key can see it still depends on the permissions of the identity behind it, at datastore, field and row level.
So the practical answer to "what can this integration see" is the intersection of the gates and the identity — and the second is the one you control per integration.
If something you need is blocked
Where a system datastore is genuinely required, the switch is the supported route. Where something on the sensitive list is required, the answer is that it is not available and the requirement needs rethinking — usually it turns out that a derived view of the data, in a datastore of your own, is what was actually wanted.
Worked example
An integration needs currency codes and a customer list. The system-table switch is turned on so currencies are reachable, and the integration's identity is granted read on the customer datastore and nothing else. Its OpenAPI spec lists exactly those two, which is checked before the partner writes a line of code.
Recommendations
- Read the spec as the key rather than reasoning about the gates.
- Turn the switch on for a reason, not as a default.
- Do not try to route around the sensitive list — model what you need instead.
- Narrow by identity, which is the control you own.