Integrations at a glance
Purpose
No system stands alone. Integrations are the orderly place where foreign systems are connected — and above all the place where the credentials for them live.
The most important property is the clear direction. Two routes are kept cleanly apart, because they have to be revoked separately:
| Direction | With what | Managed under |
|---|---|---|
| Foreign system in to us | API/MCP token | API & MCP tokens |
| Us going out | Integration | Integrations |
Scope
- Credentials encrypted and write-only. A stored key can be overwritten but not read back — not
even with administrative permissions.
- Provider presets for known services pre-fill the expected configuration keys. That is more than
convenience: a typo in a key name looks like a wrong password from the outside.
- The free route stays open — any system with key/value configuration can be connected.
- Multiple connections to the same provider, per brand or per account for instance.
- Deactivate rather than delete to pause a connection temporarily.
Interplay
Incoming access runs over the API with the respective account's permissions. Whatever is changed as a result of a connection appears in traceability. Processes are triggered by functional modules or by the automation engine.
Limits
- An integration is not a rule engine. What should happen when belongs in the
automation engine; the integration is the wire, not the decision.
- AI providers do not belong here but in the AI platform.
- Credentials cannot be read back. Whoever needs a value fetches it from the provider.
- An expired token does not announce itself. Expiry dates want monitoring, not hoping.