What is on the Integrations page?
Every capability the engine can connect: the commerce platform, read-only and feeding everything; a helpdesk; a returns platform; warehouse and packing; people counting; email marketing; web behaviour analytics; search console; social platforms; outbound email for manager messages; and the AI model providers.
Each card shows whether it is connected, its health, its last successful run and what it contributes. A brand can see at a glance which parts of the picture are live and which are missing, which is also why the surfaces can say Not reported honestly.
- The commerce platform: read-only, required, and the source everything else is joined to.
- Helpdesk, returns, warehouse and packing, people counting: the operational systems.
- Email marketing, behaviour analytics, search console and social: the growth systems.
- Outbound email for manager and supervision messages.
- The AI provider cards: one default each for text, images and video, swappable at any time.
Why secrets are write-only
An API key that can be read back out of a platform is a key that can leak from it. On this page a secret can be entered and replaced but never displayed, so the platform holds what it needs to work and cannot hand it to anyone, including a user who asks.
Where the system supports OAuth, that is used instead, so the brand grants a scoped connection it can revoke from its own side without touching the engine.
Rotating a secret is the same action as setting one: paste the new value and the old is replaced, without either ever being displayed. Where a provider supports scoped tokens, the page asks for the narrowest scope that supports the capability.
Capability, not vendor
The page is organised by what a system contributes rather than by brand name: tickets, return records, packing performance, footfall, reach, insights. That framing is deliberate, because it makes the architecture obvious: the engine needs a capability, and a specific vendor is one way to provide it.
Behind each capability sits an adapter. That is why another commerce platform is a build rather than a rewrite, and why a brand switching helpdesk does not lose its support history's shape.
It also keeps the language on the page honest with a brand that has not chosen a vendor yet: the question is whether the brand wants footfall joined to sales, not whether it wants a particular counter.
AI providers are configuration
Text, image and video model vendors are cards on the same page: one default for each, swappable. The platform is vendor-independent by design, and the AI performance surface shows what each choice costs in latency, reliability and tokens.
For a brand, that means a provider outage, a price change or a policy change is handled by changing a card rather than by waiting for the platform to be rewritten.
Why add one system at a time?
The commerce platform is the first and the only required one; everything else earns its place. A brand with heavy returns connects the returns platform next. A brand with shops connects people counting. A brand pushing win-back lists connects the email tool.
Each addition unlocks specific surfaces and specific joins, and the page says which. That makes the rollout a sequence of small decisions rather than a project.
What connecting does not do
It does not grant write access to the store: the commerce connection is read-only and cannot be configured otherwise. It does not share data between brands. And it does not turn on unattended sending anywhere; that remains a separate, explicit switch per class of action.
On ftes.ai, the same integrations carry the roles' own connections, and a role that loses a connection says so in its Setup tab rather than working from stale data.
In what order should a brand connect systems?
Commerce first, because everything is joined to it. Then the system that covers the brand's largest known problem: returns for a brand with heavy returns, people counting for a brand with shops, the helpdesk for a brand drowning in tickets.
Growth systems last, because their value depends on the commerce joins already being in place. A search console connection is far more useful once articles are being published against a Brand Brain than it is on day one.