# Credentials

Authorize an account on another service and understand how its Credential maintains a Secret in one Environment.

Last updated: 2026-10-22

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](/configuration/secrets). A Credential handles an
account authorization through an [OAuth app](/configuration/oauth-apps).

## Account, app and Secret

These are three related resources:

| Resource | What it represents |
| --- | --- |
| OAuth app | The registration used to ask the service for authorization |
| Credential | The account authorization obtained through that app, for one Environment |
| Matching Secret | The access token exposed to a Workflow as `secrets.NAME` |

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](/configuration/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.

## Authorizing an account

Your Agent checks the available managed and custom OAuth apps, then prepares the target
Environment, selected app, Secret name and requested
[OAuth scopes](/configuration/oauth-apps#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](/agents/sensitive-data) for the human, Agent and runtime
boundaries.

## Refresh and reconnection

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](/configuration/oauth-apps#changes-can-affect-several-credentials)
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

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.