Integrations

Overview
Integrations are the connections to foreign systems — the place where credentials for external services live.
They differ from API tokens in direction: a token lets a foreign system in to us, an integration lets us out. Both directions are managed separately because they have to be revoked separately.
Core tasks
Create an integration. New integration requires a name, a provider and the configuration as key/value pairs.
Use a provider preset. For known services — LinkedIn, Meta (Facebook/Instagram) and X — a preset pre-fills the provider and the expected configuration keys. That saves looking up exactly what a key has to be called. The free route without a preset remains available for everything else.
Store credentials. Token keys such as access_token or page_access_token are stored encrypted and write-only: on reloading they appear masked as ********. You can overwrite them but not read them back — not even as an administrator.
Activate. The active state decides whether the connection is used. The list shows name, provider, status and modification date.
Mind the connection notices. Above the list, connections report a setup that no longer works — for example Sendcloud while the shipping method is still a number from the old interface: no labels are created with it any more. The notice names the number and what to enter instead; the same notice appears in the log after a system update. Shipping cost rules that prescribe such a number as the shipping method are reported the same way (with identifier, zone and carrier — fix them under Settings → Shipping, field Shipping method), as are shipments without a label carrying such a number: buying their label again fails, so cancel them and create them again with the code of the shipping option. Likewise OctiConnect flows whose shipping building block stored such a number — the notice names the flow and links to it.
Fields in detail
| Field | Required | Values / format | What it does |
|---|---|---|---|
Provider provider | yes | an available provider, max. 100 characters | What is connected to. The provider determines which settings appear below and which login is needed. |
Name name | yes | text, max. 255 characters | What the connection is called. With several accounts at the same provider it is the only distinction — "Google Workspace accounting" rather than "Google". |
Settings config | no | depending on the provider | Credentials, keys, targets. Secrets are stored encrypted and never shown again; entering them anew replaces them. |
Brand brandId | no | one of your brands | Which brand the connection applies to. A separate account per brand is possible and often necessary. |
Active active | no | yes/no | Whether the connection is used. Off pauses it without losing the setup — the first move when a provider misbehaves. |
If a login expires, the connection rests visibly and reports itself instead of quietly doing nothing. That is the difference between "nothing has arrived for three weeks" and a message on day one.
Settings & permissions
- No route permission of its own. The page is reachable; creating and changing is checked by the
server.
- Credentials cannot be read back. Whoever needs the value fetches it from the provider, not from
here.
- AI providers do not belong here. Their access lives under AI settings.
- A provider may appear several times — per brand or per account, for instance.
FAQ & troubleshooting
The connection fails although the key is correct. Check the key names in the configuration. A provider preset names them correctly; entered by hand, typos creep in that look like a wrong password from the outside.
A token has expired. Renew it at the provider and enter the new value. The old one cannot be inspected — so a comparison is not possible.
I can no longer see the stored value. By design. Credentials are stored encrypted and displayed masked.
We want to stop a connection temporarily. Deactivate it rather than deleting the credentials.