Integrations
The Integrations page is where the platform's connections to external services live. An integration holds one service's credentials and endpoints — an AWS role, an Office 365 tenant, an LDAP server, a Slack token — separately from the pipeline that uses it. Most integrations are created for you when you install an application; this page is where they are read back, edited, and created on their own.
Menu path: Platform → Integrations · URL path: /platform/integrations
Page Layout
Under the Integrations title and the subtitle A list of active integrations and integration types., the page has the same two-region shape as Applications:
- A view selector on the left with two entries.
- The content region on the right, showing whichever view is selected.
A blue Back to Applications button sits in the page header, in the same place the Applications page puts View Integrations. The two buttons are a round trip between the pages, and /platform/integrations and /platform are the only two URLs involved — switching between the views below does not change either.
View Selector
| Entry | What it shows |
|---|---|
| Existing Integrations | The integrations currently configured on this platform, grouped by category — the view the page opens on. |
| New Integration | The catalog of 58 integration types, with an Add dialog behind each one. |
How integrations relate to applications
An application is a whole pipeline: a source, the processors that parse it, the sinks it writes to. An integration is only the connection at the source end. Installing an application from a template usually creates one — the Add Integration lines in an application's Actions list name the integrations that install produced, and they then appear here under Existing Integrations.
That split is why this page matters even when every source was installed from a template:
- Credentials are edited here, not there. An application's details panel is read-only, so a rotated client secret is applied to the integration on this page rather than by reinstalling the application around it.
- One integration can serve several applications. AWS roles are the exception to where such a shared credential lives. The Pre-defined AWs Role drop-down on every AWS setup form lists roles registered under Settings → AWS Roles, not integrations on this page.
- Some integrations have no application. A pipeline built by hand from Platform → Processors still needs its source's credentials, and outbound connections — Slack, PagerDuty, ServiceNow — exist only here.
The two catalogs do not line up one-to-one. The 58 integration types here are the connection primitives; the application templates are packaged pipelines built on top of them. Several templates share one type — the three Office 365 templates all produce Office365-family integrations — and several types have no template at all, which is what makes them worth knowing about.