Skip to content
AletheiaAletheiaAletheia docs

Ingest tokens

An ingest token authenticates your CI pipeline to Aletheia. It is deliberately not a user token.

Creating one

Section titled “Creating one”

Go to Administration → Ingest tokens (/admin/ingest-tokens) and create a token. The raw value is shown once, at creation. Copy it into your CI secret store then; Aletheia stores only a hash and cannot show it to you again.

If you lose it, revoke it and create another. There is no recovery path, which is the point.

What a token can do

Section titled “What a token can do”

An ingest token can call the /api/v1/ingest/* endpoints and nothing else. It cannot read your inventory, list your resources, or reach any other part of the API. If one leaks, the exposure is limited to someone being able to submit plan and execution records to your organization.

Tokens are scoped to your organization. They can optionally be scoped to a single repository as well — a repository-scoped token used against a different repository is rejected with 403.

Revoking

Section titled “Revoking”

Revoke a token at any time from the same screen. Revocation is immediate and affects nothing else: no user is logged out, and no other token stops working.

Rotating is therefore safe to do routinely — create the new token, update the CI secret, then revoke the old one.

Why it is separate from user authentication

Section titled “Why it is separate from user authentication”

A CI pipeline runs unattended, often on infrastructure you do not fully control, and its credential sits in a secret store read by every job in the repository. Tying that to a person’s login would mean a leaked CI secret exposes everything that person can see, and a person leaving the company breaks the pipeline.

A dedicated, narrowly scoped, individually revocable credential avoids both.

Where to go next

Section titled “Where to go next”