Back to Details

managing-api-tokens

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- TIER:1 -->
<!-- TIER:1 -->

Managing API Tokens

管理API令牌

An API token (the API resource 
accesstoken
, shown as API tokens in the UI) is a bearer credential that authenticates programmatic calls into Celigo -- the native integrator.io REST API, any custom APIs you have built in the account, and your MCP servers. It is the machine-to-machine equivalent of a user login: where a person signs in through the UI, a script presents an API token. Managing tokens is an owner/administrator capability.
Two things to keep straight up front:
  • Direction is inbound. An API token governs traffic coming into Celigo -- the opposite of connections and iClients, which authenticate Celigo's outbound calls out to external systems. This is the most common conceptual mix-up; see API Token vs Connection OAuth Token.
  • The token value is a real secret. It is masked as 
    ******
    in normal responses and shown in full only once, at generation. Treat it like a password: never paste a real token into chat and never read one back.
Concerns when managing API tokens:
  • Token kind -- a personal access token (PAT) tied to your own user vs an account API token owned by the account. See Personal Access Tokens (PATs) vs Account API Tokens.
  • Access scope -- 
    fullAccess
    (whole account) vs least-privilege resource scoping (
    _connectionIds
    , 
    _exportIds
    , 
    _importIds
    , 
    _apiIds
    , 
    _mcpServerIds
    ). The two are mutually exclusive.
  • Lifecycle -- generate, revoke, delete (a token must be revoked before it can be deleted).
  • Expiry -- optional 
    autoPurgeAt
    self-destruct for short-lived tokens.
  • Secret handling -- capture the value once at generation; rotate rather than reuse a leaked token.
  • Auto-managed variants -- connector integration tokens and APIM tokens you do not hand-craft.
API tokens are an account-administration concern, not a flow or integration resource.
API令牌（API资源
accesstoken
，在UI中显示为API tokens）是一种承载凭证，用于对进入Celigo的程序化调用进行身份验证——包括原生integrator.io REST API、您在账户中构建的所有自定义API，以及您的MCP服务器。它相当于机器对机器版本的用户登录：用户通过UI登录，而脚本则出示API令牌。管理令牌是所有者/管理员的权限。
首先需要明确两点：
  • 方向为入站：API令牌管控进入Celigo的流量——这与连接和iClients相反，后者用于验证Celigo向外调用外部系统的出站请求。这是最常见的概念混淆；请参阅API令牌 vs 连接OAuth令牌。
  • 令牌值是真正的机密：在常规响应中它会被掩码为
    ******
    ，仅在生成时完整显示一次。请像对待密码一样对待它：永远不要将真实令牌粘贴到聊天中，也不要口头复述。
管理API令牌时需要关注的要点：
  • 令牌类型——绑定到您个人用户的个人访问令牌（PAT）与账户拥有的账户API令牌。请参阅个人访问令牌（PAT） vs 账户API令牌。
  • 访问范围——
    fullAccess
    （全账户访问）与最小权限资源范围（
    _connectionIds
    、
    _exportIds
    、
    _importIds
    、
    _apiIds
    、
    _mcpServerIds
    ）。两者互斥。
  • 生命周期——生成、撤销、删除（令牌必须先撤销才能删除）。
  • 过期机制——可选的
    autoPurgeAt
    自动销毁功能，适用于短期令牌。
  • 机密处理——生成时立即捕获令牌值；令牌泄露后应轮换而非复用。
  • 自动管理变体——连接器集成令牌和APIM令牌，无需手动创建。
API令牌属于账户管理范畴，而非流程或集成资源。

What API Tokens Are For

API令牌的用途

Anything that needs to talk to Celigo without a human at a keyboard:
  • CI/CD pipelines -- a deploy step that clones an integration, flips a setting, or runs a flow on release.
  • Monitoring and alerting -- a script polling flow or error state and paging on failures, or pushing metrics to an observability stack.
  • Calling your custom APIs and MCP servers -- external callers authenticate into APIs and MCP servers you have published using an API token (one of an MCP server's accepted auth modes).
  • Ad-hoc API access -- hitting the integrator.io REST API from Postman, a notebook, or a one-off script.
When a user says "a token for our script", "authenticate our pipeline to Celigo", "call the Celigo API from our server", or "let our monitoring hit the API" -- that is an API token.
任何无需人工操作即可与Celigo交互的场景：
  • CI/CD流水线——部署步骤中克隆集成、修改设置，或在发布时运行流程。
  • 监控与告警——轮询流程或错误状态并在故障时发送通知的脚本，或将指标推送到可观测性堆栈的脚本。
  • 调用自定义API和MCP服务器——外部调用者使用API令牌（MCP服务器支持的认证方式之一）对您发布的API和MCP服务器进行身份验证。
  • 临时API访问——从Postman、笔记本或一次性脚本调用integrator.io REST API。
当用户提到“脚本用的令牌”、“让我们的流水线向Celigo认证”、“从我们的服务器调用Celigo API”或“让我们的监控系统访问API”时，指的就是API令牌。

API Token vs Connection OAuth Token

API令牌 vs 连接OAuth令牌

"Access token" is overloaded -- the underlying resource is even named 
accesstoken
-- so this is the mix-up to head off first. Same two words, opposite directions, different resources:
integrator.io API tokenConnection OAuth access token
DirectionInbound -- authenticates calls into CeligoOutbound -- authenticates Celigo's calls out to an external system
Proves identityAn external caller → CeligoCeligo → the external system
Lives onThe account (
accesstoken
resource -- this skill)		A specific connection (produced by its OAuth flow, optionally via an iClient)
Managed withThis skillconfiguring-connections
The test: who is proving identity to whom? An external caller proving it may use your account = API token (this skill). Celigo proving it may call their system = the connection's OAuth token.
It is also distinct from user permissions: a user record is a person's access to the account; an API token is a machine's. See managing-users.
“Access token”一词存在歧义——底层资源甚至被命名为
accesstoken
——因此首先要澄清这个混淆。同样的两个词，方向相反，对应不同的资源：
integrator.io API令牌连接OAuth访问令牌
方向入站——验证进入Celigo的调用出站——验证Celigo向外调用外部系统的请求
身份验证对象外部调用者 → CeligoCeligo → 外部系统
存储位置账户（
accesstoken
资源——本技能）		特定连接（由其OAuth流程生成，可通过iClient生成）
管理方式使用本技能配置连接
判断方法：**谁向谁证明身份？**外部调用者证明其可使用您的账户 = API令牌（本技能）。Celigo证明其可调用对方系统 = 连接的OAuth令牌。
它也与用户权限不同：用户记录是个人对账户的访问权限；API令牌是机器对账户的访问权限。请参阅管理用户。

Personal Access Tokens (PATs) vs Account API Tokens

个人访问令牌（PAT） vs 账户API令牌

Celigo has two kinds of inbound bearer token. Both live under the account's API tokens view, and both are sent the same way (
Authorization: Bearer <token>
) -- the integrator.io REST API and the Celigo CLI accept either:
Personal access token (PAT)Account API token
Who can create oneAny user in the account -- including manage and monitor rolesOwner/administrator only
Whose access it grantsYours -- it inherits your own effective permissionsThe account's -- 
fullAccess
or an explicit resource-id allow-list
ScopingNone to configure -- it always mirrors what you can do
fullAccess
vs scope arrays (this skill's main concern)
ExpiryDefaults to 90 days; 
autoPurgeAt
up to 90 days out		Optional 
autoPurgeAt
up to 30 days out; otherwise long-lived
Managed byThe owning user only -- other users' PATs are listed but read-only to youAny owner/administrator
Best forYour own CLI profile, scripts, and ad-hoc API callsShared automation: CI/CD, monitoring, external callers of APIs and MCP servers
Rule of thumb: a PAT authenticates you; an account API token authenticates a system. A PAT is the quick self-service option -- generate one for yourself and go -- but it is bound to your account membership (
tokenType: "ashare"
): it tracks your permission changes immediately, stops working if your membership is removed, and its 90-day default expiry will arrive mid-quarter. For automation that must outlive any one person -- CI/CD especially -- prefer a least-privilege account API token, or at minimum calendar the PAT rotation.
Celigo有两种入站承载令牌。两者都位于账户的API tokens视图下，并且发送方式相同（
Authorization: Bearer <token>
）——integrator.io REST API和Celigo CLI都接受这两种令牌：
个人访问令牌（PAT）账户API令牌
创建者权限账户中的任何用户——包括管理和监控角色仅所有者/管理员
授予的访问权限您的权限——继承您当前的有效权限账户权限——
fullAccess
或明确的资源ID允许列表
范围配置无需配置——始终与您的权限一致
fullAccess
或范围数组（本技能的核心内容）
过期时间默认90天；
autoPurgeAt
最长可设置为90天		可选
autoPurgeAt
最长30天；否则长期有效
管理者仅令牌所有者——其他用户的PAT对您来说是只读的任何所有者/管理员
最佳适用场景您自己的CLI配置文件、脚本和临时API调用共享自动化：CI/CD、监控、自定义API和MCP服务器的外部调用者
经验法则：PAT验证您的身份；账户API令牌验证系统的身份。 PAT是快速自助选项——为自己生成一个即可使用，但它与您的账户成员身份绑定（
tokenType: "ashare"
）：它会立即跟踪您的权限变化，若您的账户成员身份被移除则停止生效，并且默认90天的过期时间会在季度中期到来。对于必须不受单个用户影响的自动化——尤其是CI/CD——首选最小权限的账户API令牌，或者至少提前安排PAT的轮换计划。

Token Anatomy

令牌结构

FieldTypePurpose
name
/ 
description
stringWhat the token is for -- the only thing identifying it in the UI and audit logs. Use a purpose name (
CI/CD Pipeline
, 
Prod Monitoring
).
token
string (secret)The bearer value. Masked as 
******
 in standard responses; the real value is shown only at generation.
fullAccess
booleanToken can reach any resource in the account. Mutually exclusive with the scope arrays.
_connectionIds
, 
_exportIds
, 
_importIds
, 
_apiIds
, 
_mcpServerIds
array of idsLeast-privilege scope -- the token reaches only the listed resources. Mutually exclusive with 
fullAccess
.
revoked
boolean
true
disables the token (authentication stops immediately). Must be 
true
before the token can be deleted.
autoPurgeAt
timestampOptional self-destruct time (within 30 days for account API tokens; up to 90 days for PATs). The record is removed automatically once it passes.
apim
booleanMarks an APIM-managed token. APIM tokens cannot be deleted.
_integrationId
/ 
_connectorId
idPresent on auto-managed connector integration tokens (set by the platform, not hand-crafted).
tokenType
/ 
_aShareId
string / idPresent on PATs: 
tokenType: "ashare"
binds the token to the creating user's account membership. Absent on account API tokens.
The shape to remember: a named secret, plus an access scope that is either everything (
fullAccess
) or an explicit allow-list of resource ids.
字段类型用途
name
/ 
description
字符串令牌的用途——这是UI和审计日志中唯一的标识信息。请使用描述用途的名称（如
CI/CD Pipeline
、
Prod Monitoring
）。
token
字符串（机密）承载值。在标准响应中掩码为
******
；真实值仅在生成时显示。
fullAccess
布尔值令牌可访问账户中的所有资源。与范围数组互斥。
_connectionIds
, 
_exportIds
, 
_importIds
, 
_apiIds
, 
_mcpServerIds
ID数组最小权限范围——令牌仅能访问列出的资源。与
fullAccess
互斥。
revoked
布尔值
true
表示禁用令牌（身份验证立即停止）。令牌必须先设置为
true
才能被删除。
autoPurgeAt
时间戳可选的自动销毁时间（账户API令牌最长30天；PAT最长90天）。时间到达后记录会自动删除。
apim
布尔值标记为APIM管理的令牌。APIM令牌无法删除。
_integrationId
/ 
_connectorId
ID自动管理的连接器集成令牌会包含此字段（由平台设置，无需手动创建）。
tokenType
/ 
_aShareId
字符串 / IDPAT会包含此字段：
tokenType: "ashare"
将令牌与创建用户的账户成员身份绑定。账户API令牌无此字段。
需要记住的结构：一个命名的机密，加上一个访问范围——要么是全部资源（
fullAccess
），要么是明确的资源ID允许列表。

Quick Reference

快速参考

Access Scope Decision Matrix

访问范围决策矩阵

The token will...ScopeSet
Serve one automation touching specific resourcesLeast-privilege (default)One or more of 
_connectionIds
, 
_exportIds
, 
_importIds
, 
_apiIds
, 
_mcpServerIds
; omit 
fullAccess
Call one custom API or one MCP serverLeast-privilege
_apiIds
or 
_mcpServerIds
scoped to that resource
Run genuinely account-wide automation (backup/export tool, admin provisioning)Full access (the exception)
fullAccess: true
; omit all scope arrays
Default toward least privilege: scope a token to exactly the resources its automation touches. A monitoring script that reads two flows' errors does not need account-wide access. Reserve 
fullAccess
for automation that would be impractical to enumerate, and treat those tokens as the highest-value secrets to rotate and audit.
令牌将用于...范围设置
仅访问特定资源的单一自动化最小权限（默认）设置
_connectionIds
、
_exportIds
、
_importIds
、
_apiIds
、
_mcpServerIds
中的一个或多个；不设置
fullAccess
调用一个自定义API或一个MCP服务器最小权限将
_apiIds
或
_mcpServerIds
范围限定为该资源
真正的全账户自动化（备份/导出工具、管理员配置）完全访问（例外情况）设置
fullAccess: true
；不设置任何范围数组
默认选择最小权限：将令牌范围限定为其自动化流程实际需要访问的资源。仅读取两个流程错误信息的监控脚本不需要全账户访问权限。仅当枚举资源不切实际时才使用
fullAccess
，并将这些令牌视为需要轮换和审计的高价值机密。

Minimum Fields

必填字段

Generating a token requires at minimum:
  • name
    -- a purpose-descriptive label (strongly recommended; it is the only identifier in the UI and audit logs)
  • Exactly one access model: 
    fullAccess: true
    or at least one scope array (
    _connectionIds
    , 
    _exportIds
    , 
    _importIds
    , 
    _apiIds
    , 
    _mcpServerIds
    ). Setting both fails validation.
You never supply the 
token
value -- it is generated by the platform and returned masked.
生成令牌至少需要以下字段：
  • name
    ——描述用途的标签（强烈推荐；这是UI和审计日志中唯一的标识）
  • 恰好一种访问模式：
    fullAccess: true
    或至少一个范围数组（
    _connectionIds
    、
    _exportIds
    、
    _importIds
    、
    _apiIds
    、
    _mcpServerIds
    ）。同时设置两者会验证失败。
您无需提供
token
值——它由平台生成并以掩码形式返回。

When You Need This Skill

何时需要使用本技能

  • Creating, scoping, rotating, revoking, or deleting an API token
  • A script, pipeline, monitor, or external client must authenticate into integrator.io
  • Choosing between a personal access token and an account API token
  • Deciding between account-wide and scoped programmatic access
  • Untangling an "access token" question -- is it inbound (this skill) or a connection's outbound OAuth token (see configuring-connections)
  • 创建、设置权限、轮换、撤销或删除API令牌
  • 脚本、流水线、监控系统或外部客户端需要向integrator.io进行身份验证
  • 在个人访问令牌和账户API令牌之间做出选择
  • 在全账户访问和限定范围的程序化访问之间做出决策
  • 理清“access token”相关问题——它是入站的（本技能）还是连接的出站OAuth令牌（请参阅配置连接）

Related Skills

相关技能

  • managing-users > Access Strategy Decision Matrix -- API tokens authenticate machines; user records authenticate people. Both are owner/administrator-controlled access.
  • configuring-connections > iClients (OAuth Credential Stores) -- a connection's OAuth access token authenticates Celigo's outbound calls; do not confuse it with an inbound API token.
  • building-apis > API Modes -- custom APIs have no authentication of their own; callers authenticate with an API token.
  • building-mcp-servers > How to Build an MCP Server -- MCP servers accept an API token as one of their auth modes.
<!-- TIER:2 -->
  • 管理用户 > 访问策略决策矩阵——API令牌验证机器身份；用户记录验证个人身份。两者均由所有者/管理员控制访问权限。
  • 配置连接 > iClients（OAuth凭证存储）——连接的OAuth访问令牌验证Celigo的出站调用；请勿将其与入站API令牌混淆。
  • 构建API > API模式——自定义API本身无身份验证机制；调用者需使用API令牌进行身份验证。
  • 构建MCP服务器 > 如何构建MCP服务器——MCP服务器接受API令牌作为其认证方式之一。
<!-- TIER:2 -->

How to Manage API Tokens

如何管理API令牌

1. Confirm this is an inbound-auth need

1. 确认这是入站认证需求

Before generating anything, confirm the requirement is a machine calling into Celigo. If instead something needs to authenticate out to an external system (Salesforce, NetSuite, an HTTP API), that is a connection's OAuth access token -- not an API token. Use configuring-connections. See API Token vs Connection OAuth Token.
Then decide the token kind. For your own CLI profile, scripts, or ad-hoc calls, the fastest path is a personal access token -- self-service in the UI, no scoping to design, 90-day default expiry. For shared or long-lived automation, continue below with an account API token. See Personal Access Tokens (PATs) vs Account API Tokens.
在生成任何令牌之前，确认需求是机器调用Celigo。如果是需要向外部系统（Salesforce、NetSuite、HTTP API）进行身份验证，则属于连接的OAuth访问令牌——而非API令牌。请使用配置连接。请参阅API令牌 vs 连接OAuth令牌。
然后确定令牌类型。对于您自己的CLI配置文件、脚本或临时调用，最快的方式是使用个人访问令牌——UI中自助生成，无需设计范围，默认90天过期。对于共享或长期运行的自动化，请继续下文使用账户API令牌。请参阅个人访问令牌（PAT） vs 账户API令牌。

2. Audit existing tokens

2. 审计现有令牌

bash
celigo accesstokens list
celigo accesstokens get <id>
Review 
name
/
description
(is the purpose clear?), 
fullAccess
vs the scope arrays, 
revoked
, 
autoPurgeAt
, and whether it is an auto-managed 
apim
or connector token. Revoke or purge stale tokens you no longer recognize.
bash
celigo accesstokens list
celigo accesstokens get <id>
查看
name
/
description
（用途是否明确？）、
fullAccess
与范围数组、
revoked
、
autoPurgeAt
，以及它是否是自动管理的
apim
或连接器令牌。撤销或清除您不再需要的陈旧令牌。

3. Decide the scope

3. 确定范围

Use the Access Scope Decision Matrix. The honest question when someone asks for a token is "what will it actually call?" -- then scope to exactly that. Default to one or more scope arrays; reserve 
fullAccess
for genuinely account-spanning automation.
Scope arrays hold real resource 
_id
s. If you only have resource names, resolve them to ids first, then place the ids in the arrays:
bash
celigo account search "<resource-name>"
If you cannot resolve the ids up front, generate the token and add scope in the UI rather than leaving it 
fullAccess
by default.
使用访问范围决策矩阵。当有人请求令牌时，最实在的问题是“它实际会调用什么？”——然后将范围限定为恰好需要的资源。默认选择一个或多个范围数组；仅当确实需要全账户访问时才使用
fullAccess
。
范围数组包含真实的资源
_id
。如果您只有资源名称，请先将其解析为ID，再将ID放入数组：
bash
celigo account search "<resource-name>"
如果您无法预先解析ID，可以先生成令牌，然后在UI中添加范围，而不是默认设置为
fullAccess
。

4. Generate the token (one per consumer)

4. 生成令牌（每个消费者一个）

Default to one token per consumer -- per pipeline, per script, per external client. Independent tokens mean a leak or decommission affects exactly one consumer (you revoke that token and nothing else breaks) and the audit log attributes activity to the right caller. A single shared token turns every revocation into an outage for all of them.
Build the token JSON (
name
/
description
, plus either 
fullAccess: true
or the scope arrays) and create it:
bash
celigo accesstokens create < token.json
Capture the secret once. The generated 
token
value is shown only at creation and masked (
******
) forever after. Copy it directly into the consuming system's secret store -- never into chat, a ticket, or a commit. Creating is not idempotent: a create that appears to fail may still have minted a token, so verify with 
celigo accesstokens list
before retrying rather than minting a duplicate.
默认每个消费者一个令牌——每个流水线、每个脚本、每个外部客户端一个。独立令牌意味着泄露或停用只会影响一个消费者（您只需撤销该令牌，其他不受影响），并且审计日志会将活动归因于正确的调用者。单个共享令牌会导致每次撤销都影响所有消费者，造成服务中断。
构建令牌JSON（
name
/
description
，加上
fullAccess: true
或范围数组）并创建：
bash
celigo accesstokens create < token.json
立即捕获机密。生成的
token
值仅在创建时显示，之后永远掩码为
******
。直接将其复制到消费者系统的机密存储中——永远不要复制到聊天、工单或提交记录中。创建操作不是幂等的：看似失败的创建可能已经生成了令牌，因此在重试前请用
celigo accesstokens list
验证，避免生成重复令牌。

5. Set an expiry for temporary access

5. 为临时访问设置过期时间

For a contractor engagement, a one-off migration, or a demo, set 
autoPurgeAt
(within 30 days for account API tokens; PATs allow up to 90 and default to 90) so the token cleans itself up instead of lingering as a forgotten standing credential:
bash
celigo accesstokens get <id> > token.json
对于承包商项目、一次性迁移或演示，请设置
autoPurgeAt
（账户API令牌最长30天；PAT最长90天，默认90天），这样令牌会自动清理，不会成为被遗忘的长期凭证：
bash
celigo accesstokens get <id> > token.json

set "autoPurgeAt" to an ISO timestamp within the next 30 days

将"autoPurgeAt"设置为未来30天内的ISO时间戳

celigo accesstokens update <id> < token.json

For ongoing automation a permanent token is fine -- pair it with a rotation habit: generate the replacement, cut the consumer over, then revoke the old one.
celigo accesstokens update <id> < token.json

对于持续运行的自动化，永久令牌是可行的——但要配合轮换习惯：生成替换令牌，切换到新令牌，然后撤销旧令牌。

6. Revoke, then delete

6. 先撤销，再删除

Revoke and delete are sequential, not alternatives:
  • Revoke the instant a token leaks or its consumer is retired. Authentication stops immediately while the record (and its audit trail) is preserved. Revoking is just an update that sets 
    revoked: true
    :
bash
celigo accesstokens get <id> > token.json
撤销和删除是顺序操作，而非替代操作：
  • 撤销：一旦令牌泄露或其消费者停用，立即撤销。身份验证立即停止，同时保留记录（及其审计轨迹）。撤销只需更新
    revoked: true
    ：
bash
celigo accesstokens get <id> > token.json

set "revoked": true in token.json

在token.json中设置"revoked": true

celigo accesstokens update <id> < token.json

- **Delete** only after the token is revoked -- revoke-before-delete is enforced. Deletion is a soft delete; the record is purged permanently 30 days later:

```bash
celigo accesstokens delete <id>
APIM tokens (
apim: true
) are the exception: they cannot be deleted at all -- revoking is the only lever.
celigo accesstokens update <id> < token.json

- **删除**：仅在令牌已撤销后执行——平台强制要求先撤销再删除。删除是软删除；记录会在30天后永久清除：

```bash
celigo accesstokens delete <id>
APIM令牌（
apim: true
）是例外：它们完全无法删除——只能撤销。

CLI Commands

CLI命令

bash
undefined
bash
undefined

CRUD

CRUD操作

celigo accesstokens list celigo accesstokens get <id> celigo accesstokens create < token.json # generates the secret; shown only once celigo accesstokens update <id> < token.json # rename, re-scope, set autoPurgeAt, or revoke (revoked: true) celigo accesstokens delete <id> # only after revoked: true; APIM tokens cannot be deleted
celigo accesstokens list celigo accesstokens get <id> celigo accesstokens create < token.json # 生成机密；仅显示一次 celigo accesstokens update <id> < token.json # 重命名、重新设置范围、设置autoPurgeAt或撤销（revoked: true） celigo accesstokens delete <id> # 仅在revoked: true时可执行；APIM令牌无法删除

Resolve resource names to ids for scope arrays

将资源名称解析为ID以用于范围数组

celigo account search "<resource-name>"

**UI alternative:** manage tokens under the account's **API tokens** view -- both PATs and account API tokens live there, and it is where you generate a PAT for yourself. The UI is the easiest place to copy a freshly generated token value into a secret store.

**API alternative:** the same resource is the integrator.io REST `accesstoken` type (plural path `/v1/accesstokens`): `POST` to generate, `PUT .../{id}` to update or revoke (`revoked: true`), `DELETE .../{id}` after revoking.

<!-- TIER:3 -->
celigo account search "<resource-name>"

**UI替代方案**：在账户的**API tokens**视图下管理令牌——PAT和账户API令牌都在此处，您也可以在此为自己生成PAT。UI是将新生成的令牌值复制到机密存储的最便捷方式。

**API替代方案**：同一资源对应integrator.io REST的`accesstoken`类型（复数路径`/v1/accesstokens`）：`POST`生成，`PUT .../{id}`更新或撤销（`revoked: true`），撤销后执行`DELETE .../{id}`。

<!-- TIER:3 -->

Pre-Submit Checklist

提交前检查清单

Before generating or updating an API token, verify:
  • name
    /
    description
    states the token's purpose and consumer (it is the only identifier in audit logs)
  • Exactly one access model is set -- 
    fullAccess: true
    or scope arrays, never both (setting both fails validation)
  • fullAccess
    is justified by genuinely account-wide automation; otherwise scope to specific resource ids
  • Scope arrays contain real resource 
    _id
    s (resolved from names), not placeholders
  • For temporary access, 
    autoPurgeAt
    is set and within 30 days
  • The consumer gets its own token (not a shared one) so revocation stays isolated
  • You are ready to capture the generated secret into a secret store -- not chat, tickets, or commits
  • To delete: the token is already 
    revoked: true
    and is not an 
    apim
    token (which cannot be deleted)
在生成或更新API令牌之前，请验证：
  • name
    /
    description
    明确说明了令牌的用途和消费者（这是审计日志中唯一的标识）
  • 仅设置了一种访问模式——
    fullAccess: true
    或范围数组，从未同时设置（同时设置会验证失败）
  • fullAccess
    的使用由真正的全账户自动化需求证明；否则将范围限定为特定资源ID
  • 范围数组包含真实的资源
    _id
    （从名称解析而来），而非占位符
  • 对于临时访问，已设置
    autoPurgeAt
    且在30天内
  • 每个消费者都有自己的令牌（不共享），以便撤销操作仅影响单个消费者
  • 您已准备好将生成的机密捕获到机密存储中——而非聊天、工单或提交记录
  • 若要删除：令牌已设置为
    revoked: true
    且不是
    apim
    令牌（此类令牌无法删除）

Gotchas

常见陷阱

  1. API token = inbound; connection OAuth token = outbound. The single most common mix-up. If the thing authenticating is Celigo reaching out to another system, it is a connection's OAuth token, not an API token. See API Token vs Connection OAuth Token.
  2. The token value is a secret -- never echo it. It is masked as 
    ******
    in responses and shown in full only at generation. Never accept a token value in chat and never read one back. If a user pastes a real token, treat it as compromised: revoke it and generate a new one rather than reuse it.
  3. Capture the secret at generation -- it is shown only once. After creation the value is masked forever. If it was not captured, you must generate a replacement.
  4. fullAccess
    and the scope arrays are mutually exclusive.     Setting 
    fullAccess: true
    alongside any of 
    _connectionIds
    /
    _exportIds
    /
    _importIds
    /
    _apiIds
    /
    _mcpServerIds
    fails validation. Choose one model.
  5. Revoke before delete -- always. A token must be 
    revoked: true
    before it can be deleted; the platform enforces the order. Revoke is the instant safety action (authentication stops immediately, record preserved); delete is later cleanup (soft delete, purged after 30 days).
  6. APIM tokens cannot be deleted. Tokens marked 
    apim: true
    are managed by API management and have no delete path. Revoking is the only lever.
  7. Auto-managed tokens are not hand-crafted. Connector integration tokens (carrying 
    _integrationId
    /
    _connectorId
    ) and APIM tokens (
    apim: true
    ) are created by the platform -- do not try to author or duplicate them by hand.
  8. autoPurgeAt
    must be within 30 days -- 90 for PATs.     It is meant for short-lived tokens; a value further out is rejected. It self-deletes the record when it passes.
  9. Creating is not idempotent. A create that appears to fail may still have minted a live token. Verify with 
    celigo accesstokens list
    before retrying, or you may leave an orphaned credential.
  10. GET masks the secret; PUT replaces the record. 
    celigo accesstokens get
    returns 
    token
    as 
    ******
    , and update is a full PUT that erases omitted fields. GET first, change only the intended fields (scope, 
    revoked
    , 
    autoPurgeAt
    ), then update -- and never treat the masked value as the real secret.
  11. A PAT is yours alone -- other users' PATs are read-only. Every member's PATs appear in the account's API tokens list, but only the owning user can edit, revoke, or delete one (anyone else gets "This personal access token is owned by another user"). A credential the team must manage jointly should be an account API token.
  12. A PAT rides the owner's permissions -- and their 90-day clock. It inherits whatever the creating user can do (no scoping available), tracks permission changes immediately, stops working if the membership is removed, and expires after 90 days by default. Don't bury one in CI: use a scoped account API token there, or calendar the rotation.
  1. API令牌=入站；连接OAuth令牌=出站。这是最常见的混淆。如果身份验证的是Celigo向外调用其他系统，则属于连接的OAuth令牌，而非API令牌。请参阅API令牌 vs 连接OAuth令牌。
  2. 令牌值是机密——永远不要泄露。它在响应中掩码为
    ******
    ，仅在生成时完整显示。永远不要在聊天中接受令牌值，也不要口头复述。如果用户粘贴了真实令牌，请视为已泄露：撤销该令牌并生成新令牌，不要复用。
  3. 生成时立即捕获机密——仅显示一次。创建后令牌值会永远掩码。如果未捕获，您必须生成替换令牌。
  4. fullAccess
    与范围数组互斥    。同时设置
    fullAccess: true
    和
    _connectionIds
    /
    _exportIds
    /
    _importIds
    /
    _apiIds
    /
    _mcpServerIds
    中的任何一个会验证失败。请选择一种模式。
  5. 始终先撤销再删除。令牌必须先设置为
    revoked: true
    才能被删除；平台强制要求此顺序。撤销是即时安全操作（身份验证立即停止，记录保留）；删除是后续清理操作（软删除，30天后永久清除）。
  6. APIM令牌无法删除。标记为
    apim: true
    的令牌由API管理系统管理，无法删除。只能撤销。
  7. 自动管理的令牌无需手动创建。连接器集成令牌（包含
    _integrationId
    /
    _connectorId
    ）和APIM令牌（
    apim: true
    ）由平台创建——不要尝试手动编写或复制它们。
  8. autoPurgeAt
    必须在30天内——PAT为90天    。它适用于短期令牌；超出此范围的值会被拒绝。时间到达后记录会自动删除。
  9. 创建操作不是幂等的。看似失败的创建可能已经生成了有效的令牌。重试前请用
    celigo accesstokens list
    验证，否则可能留下孤立的凭证。
  10. GET请求掩码机密；PUT请求替换记录。
    celigo accesstokens get
    返回的
    token
    为
    ******
    ，更新操作是全量PUT，会删除未包含的字段。请先GET，仅修改目标字段（范围、
    revoked
    、
    autoPurgeAt
    ），然后更新——永远不要将掩码值视为真实机密。
  11. PAT仅属于您自己——其他用户的PAT是只读的。所有成员的PAT都会显示在账户的API令牌列表中，但只有所有者可以编辑、撤销或删除（其他人会收到“此个人访问令牌属于其他用户”的提示）。团队需共同管理的凭证应使用账户API令牌。
  12. PAT依赖所有者的权限——以及90天的过期时钟。它继承创建用户的所有权限（无法设置范围），会立即跟踪权限变化，若所有者账户成员身份被移除则停止生效，默认90天后过期。不要将PAT用于CI/CD：请使用限定范围的账户API令牌，或提前安排轮换计划。

Common Errors

常见错误

ErrorLikely CauseFix
422
validation error on create		Both 
fullAccess
and a scope array set, or neither		Set exactly one: 
fullAccess: true
or at least one scope array
422
invalid 
autoPurgeAt
Timestamp is in the past or more than 30 days outUse an ISO timestamp within the next 30 days
403 Forbidden
creating or managing a token		Caller is not an owner/administratorUse a token or login with owner/administrator access
Delete rejected / token will not deleteToken is not revoked yet, or it is an 
apim
token		Set 
revoked: true
first; APIM tokens cannot be deleted (revoke instead)
401 Unauthorized
from a script using the token		Token is 
revoked
, purged, or expired via 
autoPurgeAt
(PATs expire after 90 days by default)		Check 
revoked
/
autoPurgeAt
; generate a replacement if it was purged
"This personal access token is owned by another user"Editing, revoking, or deleting a PAT you do not ownHave the owning user manage it; for jointly managed credentials use an account API token
Token authenticates but 
403
on a specific resource		Resource is outside the token's scopeAdd the resource id to the appropriate scope array, or widen scope deliberately
Scope seems ignored / token still account-wide
fullAccess: true
is still set alongside scope arrays		Remove 
fullAccess
; scope arrays only apply when 
fullAccess
is not set
Lost the token valueSecret was not captured at generation (masked thereafter)Generate a replacement token and revoke the old one
错误可能原因修复方法
创建时出现
422
验证错误		同时设置了
fullAccess
和范围数组，或两者都未设置		仅设置其中一种：
fullAccess: true
或至少一个范围数组
autoPurgeAt
无效导致
422
错误		时间戳在过去或超过30天使用未来30天内的ISO时间戳
创建或管理令牌时出现
403 Forbidden
错误		调用者不是所有者/管理员使用所有者/管理员权限的令牌或登录
删除被拒绝/令牌无法删除令牌尚未撤销，或它是
apim
令牌		先设置
revoked: true
；APIM令牌无法删除（改为撤销）
使用令牌的脚本出现
401 Unauthorized
错误		令牌已被撤销、清除或通过
autoPurgeAt
过期（PAT默认90天后过期）		检查
revoked
/
autoPurgeAt
；若已清除则生成替换令牌
“此个人访问令牌属于其他用户”您尝试编辑、撤销或删除不属于您的PAT请所有者管理该令牌；团队共同管理的凭证请使用账户API令牌
令牌通过身份验证但访问特定资源时出现
403
错误		资源不在令牌的范围内将资源ID添加到相应的范围数组，或有意扩大范围
范围似乎被忽略/令牌仍可全账户访问同时设置了
fullAccess: true
和范围数组		移除
fullAccess
；仅当未设置
fullAccess
时范围数组才生效
令牌值丢失生成时未捕获机密（之后被掩码）生成替换令牌并撤销旧令牌