Managing API Tokens
Manage Celigo API tokens (the accesstoken resource) -- bearer credentials that authenticate inbound programmatic calls into integrator.io's REST API, custom APIs, and MCP servers. Covers personal access tokens (PATs) versus account-level API tokens, least-privilege scoping versus full access, the revoke-before-delete lifecycle, auto-purge expiry, and keeping token secrets out of chat. Use when creating, scoping, rotating, revoking, or deleting API tokens or PATs, or when distinguishing an integrator.io API token from a connection's OAuth access token.
- Skill ID
- celigo/ai/managing-api-tokens
- Publisher
- celigo
- Repository
- ai
- Installs
- 0
- Files
- 1
- Synced
- Sep 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
celigo/ai/managing-api-tokensInstalls these files- SKILL.md
What this skill tells the agent
<!-- TIER:1 -->
Managing API Tokens
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
autoPurgeAtself-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.
What API Tokens Are For
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.
API Token vs Connection OAuth Token
"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 token | Connection OAuth access token | |
|---|---|---|
| Direction | Inbound -- authenticates calls into Celigo | Outbound -- authenticates Celigo's calls out to an external system |
| Proves identity | An external caller → Celigo | Celigo → the external system |
| Lives on | The account (accesstoken resource -- this skill) | A specific connection (produced by its OAuth flow, optionally via an iClient) |
| Managed with | This skill | configuring-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.
Personal Access Tokens (PATs) vs Account API Tokens
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 one | Any user in the account -- including manage and monitor roles | Owner/administrator only |
| Whose access it grants | Yours -- it inherits your own effective permissions | The account's -- fullAccess or an explicit resource-id allow-list |
| Scoping | None to configure -- it always mirrors what you can do | fullAccess vs scope arrays (this skill's main concern) |
| Expiry | Defaults to 90 days; autoPurgeAt up to 90 days out | Optional autoPurgeAt up to 30 days out; otherwise long-lived |
| Managed by | The owning user only -- other users' PATs are listed but read-only to you | Any owner/administrator |
| Best for | Your own CLI profile, scripts, and ad-hoc API calls | Shared 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.
Token Anatomy
| Field | Type | Purpose |
|---|---|---|
name / description | string | What 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 | boolean | Token can reach any resource in the account. Mutually exclusive with the scope arrays. |
_connectionIds, _exportIds, _importIds, _apiIds, _mcpServerIds | array of ids | Least-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 | timestamp | Optional 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 | boolean | Marks an APIM-managed token. APIM tokens cannot be deleted. |
_integrationId / _connectorId | id | Present on auto-managed connector integration tokens (set by the platform, not hand-crafted). |
tokenType / _aShareId | string / id | Present 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.
Quick Reference
Access Scope Decision Matrix
| The token will... | Scope | Set |
|---|---|---|
| Serve one automation touching specific resources | Least-privilege (default) | One or more of _connectionIds, _exportIds, _importIds, _apiIds, _mcpServerIds; omit fullAccess |
| Call one custom API or one MCP server | Least-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 |
More from celigo
Use this skill in a project
Open any RiverX project, search the Skills panel for celigo/ai/managing-api-tokens, and install it in one click.