Skip to content

Managed and custom OAuth apps

Choose who maintains the app registration your account authorizes through, and understand what each route provides.

Last updated

A managed OAuth app lets you connect an account through a registration Typenode maintains. A custom OAuth app uses your organisation's registration instead. Both create a Credential whose named Secret supplies the access token your Workflow uses.

Managed or custom

Use managed when it supports the task and you want Typenode to maintain the registration. You can also use your own app when both routes work, including when your organisation prefers to own it. A Template's recommendation is a starting point, not a restriction on other suitable options.

Check the provider's support

The provider reference lists the service setup, exact OAuth scopes and access conditions for its managed route. A scope appearing on a consent screen does not by itself mean the service is ready to use. Check the required APIs, the selected app's current allowlist and any account or product requirements.

The Google reference lists the currently enabled managed APIs, their exact allowed scopes and the relevant custom-app alternatives.

If the managed route does not cover the task, use a suitable custom app. Reuse an existing registration when it has the required setup and scopes; a new task does not necessarily need a new app. Custom ownership does not remove the service's own account-access, eligibility or approval requirements.

From an OAuth app to a Workflow Secret

The OAuth app is the registration, not your account's access token. Your Agent prepares a secure connection link naming the app, Environment, scopes and Credential. You open it and approve access to your account in the service's consent screen. A prepared link alone is not a connected account.

Successful authorization creates the Credential and its matching Secret. A Workflow uses that Secret as secrets.NAME. When the grant supports refresh, Typenode keeps the token fresh through the Credential.

One app can serve several Credentials, with different names, requested scopes and connected accounts. For example, a reporting Credential and an administration Credential can use the same registration while supplying secrets.REPORTING and secrets.ADMINISTRATION. Separate Credentials do not guarantee independent consent or revocation at the outside service; its rules still apply.

For a custom app, registration happens before account consent. Enter the service's client details through Typenode's secure browser handoff, not in chat. The app's client secret identifies the registration during an OAuth exchange; use the Credential's access token, not that client secret, in your Workflow. OAuth apps explains the registration's lifecycle and protection boundaries.

Request only the task's scopes

Use the service's exact scope identifiers and request only the access the task needs. Each Template Credential declares its own scope list. A combined scope summary under a product is for reference; it is not the request for every account, and neither is the app's entire allowlist.

After consent, check the actual granted access and try a useful request against the intended resource. A connected status does not prove that the account can access every property, site or record. Do not add unrelated identity permissions merely to display an email address.

Existing Credentials

Changing a catalog recommendation or installing a newer Template does not switch an existing Credential to another app. Installed Workflows and their selected registrations stay as they are.

See Credentials for refresh and reconnection, and OAuth apps for registration changes that affect several Credentials.