Credentials

A Credential is an authorized link to your account on an Integration, such as Google or Slack. It maintains a matching Secret that Workflows use to call that service.

For an API key you enter directly, use a Secret. A Credential handles an account authorization through an OAuth app.

These are three related resources:

For example, a Credential named GOOGLE_ACCESS in staging can authorize a test Google account. Workflows in staging use secrets.GOOGLE_ACCESS. Authorize a Credential in production separately even when both Environments should use the same Google account. The same custom OAuth app registration can be used for both authorizations.

These Environments belong to your Workspace. They are separate from Typenode's own staging and production services. Your Agent selects the customer Environment where the Workflow will run.

One OAuth app can support several named Credentials, including different accounts in the same Environment. Each maintains its own matching Secret. Sharing a registration does not guarantee that the outside service isolates its consent or revocation between those Credentials.

Your Agent checks the available managed and custom OAuth apps, then prepares the target Environment, selected app, Secret name and requested OAuth scopes. These are the service's exact permission names, separately from access inside your Typenode Workspace.

A managed app uses Typenode's registration; you authorize your account without entering a client ID or client secret. With a custom app, reuse a suitable existing registration or complete its registration handoff first.

For a Template, each named Credential has its own required scopes. Request that list, rather than the combined scopes displayed for the App. A recommendation helps choose an app; it does not authorize access or require you to choose that route.

Your Agent can supply a Secret name, such as GSC_ACCESS_TOKEN, or let Typenode generate one. It receives the resolved name and uses that same name in the Workflow. Creating another Credential does not overwrite an existing name.

You complete the browser handoff and review the service's authorization request. The Agent then checks the saved Credential. A handoff link means authorization is prepared, not that the account is already connected.

Check the saved Environment, Secret name, account identity when the service supplies one, and recorded OAuth scopes against the request. Some services return no email address; Typenode does not add identity scopes just to obtain one. A connected status alone does not establish that it is the intended account. Recorded scopes do not independently verify the service's current consent. Confirm the intended account and requested access during the service's authorization step.

Finish with a read-only check against the intended account or resource. Refused or partial access may leave the task unavailable even after a browser handoff returns.

The authorization flow keeps token entry out of Agent tool arguments. Read Sensitive data and handoffs for the human, Agent and runtime boundaries.

Typenode keeps the token current when the service supports refresh. Some authorizations require you to authorize again. Temporary service failures can be retried; revoked access can require human attention.

Reconnecting authorizes the existing Credential again with its existing Environment, OAuth app, name and OAuth scopes. It is not a way to move the Credential to another Environment or request a different set of scopes. If the service rejects the OAuth app itself, repair that registration before reconnecting the account.

For different OAuth scopes, create a new Credential with a different Secret name and update the Workflow to use it. Check the replacement before removing the original Credential.

Manage the authorization through the Credential rather than manually replacing its matching Secret. Workflows keep referencing the same Secret name while Typenode maintains the token.

Deleting a Credential removes its token material from Typenode. Workflows that depend on its matching Secret can fail when they next need it. Check those dependencies before confirming deletion.

Typenode also attempts to revoke the tokens with the service. Successful local deletion does not guarantee that the service revoked the authorization. To ensure access is withdrawn at the service, remove the app's access in that service's account settings as well.