Skip to content

Ingest tokens ​

Ingest tokens authenticate and scope the shippers that push logs to HeliosLogs. Each token is pinned to one environment and, optionally, an allowlist of indexes — so a compromised shipper can only write where you intended.

Manage them under Admin → Data Ingestion → Tokens.

Admin → Data Ingestion → Tokens: require-auth switch, token creator, and token list

Ingest tokens vs. API keys

Ingest tokens authorize writing logs (/api/ingest, the shims, …) and are scoped to an env/index. API keys authorize reading via the REST API (search, aggregate, admin). Different jobs — use the right one.

Require authentication ​

By default ingestion is open — convenient for a local box. For anything exposed, turn on Require a valid token for all ingest (the switch on the Tokens tab). With it on, any ingest/shim request without a valid token is rejected with 401.

With require-auth off, a request with no token is accepted, but a request that presents an unknown bearer token is still 401 — so a misconfigured shipper fails loudly instead of writing to the wrong place.

Endpoint on/off is separate

Turning whole endpoint classes on or off (the HeliosLogs Ingest API, the compatibility APIs) is done on the Sources tab — see Pull sources. Require-auth and tokens live on the Tokens tab.

Creating a token ​

Create a token with:

  • Name — a label (e.g. fluent-bit-prod).
  • Environment — the workspace this token may write to. The token pins it; a request's ?env= or X-Helios-Env cannot override the token's env.
  • Indexes — an optional allowlist. Empty means any index within the env; otherwise writes to other indexes are rejected (and counted in errors).

The secret is shown once at creation — copy it then. Afterward the list shows only the last four characters (…9ff7); there's no way to reveal it again, so rotate (delete + recreate) if it's lost. You can disable a token without deleting it, and delete it to revoke immediately.

Presenting a token ​

Send the token in the Authorization header. Three schemes are accepted:

SchemeExampleNotes
BearerAuthorization: Bearer <token>The default for most shippers. Strict — an unknown token is 401.
SplunkAuthorization: Splunk <token>For HEC clients. Strict, like Bearer.
BasicAuthorization: Basic <base64(user:pass)>The token may be the username or the password. Lenient — an unrecognized Basic credential falls through to the open path (when require-auth is off).
bash
curl -H "Authorization: Bearer <token>" \
  -X POST 'http://localhost:7300/api/ingest?index=app' \
  --data-binary @events.ndjson

See the shipper configs for where the header goes in Fluent Bit, Vector, and the OTel Collector.

Managing tokens via the API ​

Admins (or an admin API key) can manage tokens over REST:

Method & pathAction
GET /api/admin/ingest-tokensList tokens (secrets masked) and the require-auth policy.
POST /api/admin/ingest-tokensCreate a token; the full secret is returned once.
PATCH /api/admin/ingest-tokens/:idEnable/disable a token.
DELETE /api/admin/ingest-tokens/:idRevoke a token.
PUT /api/admin/ingest-authSet the require / api-enabled / shims-enabled switches.

See Security hardening for where ingest auth fits in a production setup.