CircleCI package v1.0.0

A CircleCI personal API token, held in the client's own secret manager. The stored material must be the complete Circle-Token header value: the token itself, with no scheme prefix added. CircleCI documents the Circle-Token header as the primary API v2 authentication, and also accepts RFC 6750 bearer and HTTP Basic (token as username, blank password) forms; the query-parameter form is deprecated and must not be used.

CircleCI documents that personal API tokens grant full read and write access as the owning user with no scope reduction available, and that project API tokens are not supported on API v2 — so the only least-privilege control available is a dedicated token on an account with the minimum project access, and nothing broader; review that account's permissions before enabling. CircleCI documents no token expiry: deleting the token in user settings is the revocation path and invalidates that issued token, and rotation means deleting and recreating it.

Renewal ownership sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle itself, and it must never substitute a different credential without an approved pack change.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The registered host is circleci.com (CircleCI cloud). Self-hosted CircleCI server installations use an installer-specific host: substituting it into the endpoints, the resource locator and the egress allowlist is a pack change that requires re-review before enablement. PROJECT_SLUG, PIPELINE_ID, WORKFLOW_ID and APPROVAL_REQUEST_ID in the endpoint paths are placeholders the deployment binds to concrete values per request target (PROJECT_SLUG is the vcs-slug/org-name/repo-name triple, for example gh/example-org/example-repo); the registered paths do not change.

This pack registers only endpoints the public CircleCI API v2 documentation and its published OpenAPI specification describe: reading one project, listing a project's pipelines, listing a pipeline's workflows, listing a workflow's jobs, triggering a pipeline, and approving a pending approval job.

Documented exclusions: the newer recommended pipeline-run endpoint (which the provider documents as superseding the registered trigger), pipeline continuation, workflow rerun and cancel, job cancel, schedule and trigger management, contexts, environment variables, project settings, checkout keys, webhooks, organization administration, and every endpoint outside the registered list; each addition is a pack change and requires its own review.

Integration scope of the registered trigger: CircleCI's published OpenAPI specification states that the registered legacy trigger does not support triggering pipelines integrated with GitLab or GitHub App, and that it is superseded by a newer pipeline-run endpoint supporting pipeline definitions whose config source is github_app, github_server, github_oauth, bitbucket_dc or bitbucket_oauth — that is, all organization and pipeline types except GitLab, which neither documented trigger serves.

The registered legacy trigger therefore fits projects on the GitHub OAuth app and Bitbucket Cloud integrations, and a well-formed PROJECT_SLUG alone does not establish compatibility — confirm the project's integration type in the CircleCI web app before enabling.

Approval classification: reads sit at the minimum R0 tier. pipeline.trigger is registered as deploy at the minimum R3 tier because CircleCI documents that the request body lets the caller choose the branch or tag and pass pipeline parameters, and CircleCI pipelines commonly perform deployments — deploy is one of the designated actions requiring human approval. job.approve is registered as approve at the minimum R3 tier because an approval job is the documented gate before protected continuation of a workflow, commonly a deployment, and the approval is recorded under the caller's identity — approve is one of the designated actions requiring human approval. AAES has not been certified by CircleCI; review and test this configuration; it is not a vendor guarantee.