Third-Party Authorizations

It is a single pass: pick the service, fill in the credentials as instructed, and on save the platform calls upstream once to confirm the connection. From then on the authorization applies to all of your workflows, while the secret never appears in workflow YAML, exports, or run logs.

Division of labor with "model suppliers"

The "Integration" page has two partitions, which contain two different types of things:

• Model Providers — OpenAI, Anthropic, OpenRouter, etc. API Key of LLM service, for the Agent step to call the model.
• Third-Party Authorizations — The account authorization of the business system is used for official modules and code steps to read and write external data. That's what this page is about.

Create an authorization

1. Open Integrations → Third-party authorization. The row of category tabs narrows the list, and the search box takes a name or a use case.
2. Find the service and click Authorize. The form is generated from that service's own spec — which fields exist and what they are called comes from the service.
3. Below each field is marked where to apply, and a direct link to the upstream backend is given. Just follow it and there is no need to read additional documents.
4. save. The platform immediately sends a read-only request to the service for verification using the credentials you just filled in. After success, it will echo back the account name it recognized, allowing you to confirm that you are connecting to the correct account.

Once a service is authorized, its button becomes Add authorization — use it to connect a second account for the same service; the existing one is untouched.

What to fill in depends on the authentication method of the service

Fields marked as keys will no longer be echoed after being saved and can only be replaced as a whole; non-sensitive fields such as application ID and platform domain name are kept in plain text, making it easier for you to identify which account this authorization belongs to in the list.

The official module will automatically ask for authorization

The official module declares which service is required in its own contract:

inputs:
  - name: stripe_api_key
    type: "credential:stripe"
    required: true

When you drag a module like this into your workflow, the editor automatically does three things:

1. Register a connection variable (for example, conn_stripe) on the workflow and render it as the authorization selector for the service in the settings panel.
2. Connect this input of the module to this variable and hide it from the original input editor - you don't need to, and shouldn't, manually paste token in there.
3. Only one variable is registered for the same service. One workflow has three Stripe modules and is only authorized once.

When there is no available authorization in the selector, you can complete the authorization directly on the panel without leaving the editor; the credential pre-check before execution will also list the missing authorizations and complete them together.

Used in code step

The code step does not read the module contract and needs to explicitly declare which service is required at the top level of the workflow:

variables:
  conn_stripe: ""

variable_types:
  conn_stripe: credential:stripe

workflow:
  - step: sync_invoices
    code:
      language: javascript
      script: |
        const key = process.env.WF_CREDENTIAL_STRIPE;
        if (!key) throw new Error("Stripe authorization missing");
        // 用 key 调用 Stripe API

• The decrypted value at runtime is injected as the WF_CREDENTIAL_<PROVIDER> environment variable, which is only valid within the scope of this execution.
• When there is only one key field, the key itself is injected; when multiple key fields (such as username + password) are injected, a JSON object is injected, which needs to be parsed in the script.
• Non-key fields (application ID, platform domain name, etc.) will not be entered into environment variables. When they are needed, they are passed individually to the step as normal workflow variables.
• When the variable value is left blank, it will be automatically parsed in the order of personal → team; if the specific authorization is filled in, it will be used permanently.
• A few connections that only allow server-side proxy access do not export clear text. The workflow still holds the authorization, but the request is sent by the platform.

Individual authorization and team authorization

• Personal authorization can only be used by yourself and is suitable for personal test accounts.
• Team authorization is shared by members with access to the team and is suitable for the company's main account - colleagues do not have to go upstream to apply for a key.
• When the workflow is running, it first seeks the personal authorization of the initiator, and then the team authorization of the team to which it belongs. When sharing a workflow with colleagues, please make sure it relies on team authorization, otherwise the other party will not be able to parse it.

Connect multiple accounts to the same service

Multiple authorizations can be created for the same service, distinguished by labels, such as "Stripe · Production" and "Stripe · Sandbox". Whichever one is selected in the connection selector of the workflow, the reference to the authorization is saved, not the clear text.

How to troubleshoot if the verification fails?

security boundary

• The key is only decrypted at the moment when the external request is assembled. It does not write logs, does not enter the workflow YAML, and will not be taken out of the export and sharing workflow.
• Each service declares the domain names it allows access to, and the platform will only initiate requests to these domain names.
• Creation, update, deletion and use will leave audit records, which record the reference and source of this authorization, without clear text.
• When you suspect a leak, first go to the upstream backend to revoke the real key to block access, and then come back to delete or replace this authorization.

Services not yet in the list

Entries marked "Supported Soon" in the directory are services that have been scheduled and whose specifications have not yet been launched. The route can be seen, but cannot be connected for the time being.

Services that are not in the list at all will not stop you: use the code step to configure a common credential to directly adjust its API, or attach a MCP Server to Agent. The difference is that these two methods require you to handle the authentication details yourself, and there will be no application guidance, save and verify, and account echo.

Next

• Credentials — Storage, rotation and permission rules for model keys and general keys.
• Modules — How to read the contract of the official module and how to connect the input and output.
• MCP Integration — Mount MCP Server to Agent to cover capabilities beyond the list.