Integration represents a relationship between your product and a given external app.
Integration Definition
Integration looks like this:
In this definition:
logoUri - URL of the publicly available image with the integration logo.appUuid - uuid of the External App this integration is related to.connectorId - id of the Connector this integration uses.connectorVersion - a published version of the connector. If empty, development (unpublished) version of the connector is used.authOptions (read-only) - list of available authentication options based on the connector and integration parameters. The format of auth options matches the auth config from the Connector definition with all the Formulas resolved (if there were any).
Connector Parameters
If the connector used by an integration has parameters (for example clientId and clientSecret for OAuth), you can store their values on the integration level.
For security reasons, parameters are not saved as a part of the integration definition and are not returned in the response by default.
Read them by fetching the integration with ?includeSecrets=true (the response includes both parameters and optionsConfig), and write them with Patch integration. Where you put them depends on the connector’s auth options:
-
Single auth option — store the values at the top level, under
parameters:
-
Multiple auth options — store each option’s values under
optionsConfig.<optionKey>.parameters:
PATCH replaces parameters and optionsConfig as whole objects — there’s no deep merge. Send the full value
you want to keep; any option you omit from optionsConfig is cleared.
parameters only and don’t cover per-option values. If you’re updating parameters programmatically, prefer the ?includeSecrets=true + Patch integration approach above — it covers both.
In the UI, you can edit these values in the integration config. For a connector with a single auth option, they appear in the Parameters section:
For a connector with multiple auth options, each option has its own parameters under Options:
