Skip to content

API reference

Argus is a REST API with a web client on top of it. Everything the product does, it does through that API.

Two distinct credential types, for two distinct callers:

Caller Credential
Users JWT bearer tokens, issued at sign-in
Agents A per-agent API key, obtained by exchanging a one-time enrollment token at first boot

The two are not interchangeable. An agent key cannot act as a user, and a user token cannot submit scan results. Agent credentials and their rotation are covered in Credentials: Bootstrap vs Manual and Agents.

Worth knowing because it explains sign-out behaviour you will otherwise find puzzling. Defaults:

Setting Default Effect
Access token lifetime 30 minutes Refreshed transparently while you are active
Refresh token lifetime 24 hours
Idle timeout 15 minutes Signed out after inactivity
Absolute session lifetime 8 hours Re-authentication required regardless of activity

The absolute lifetime is the one that surprises people: a full working day at the console ends with a sign-in prompt even though you never went idle. That is intentional, and it is the control that bounds how long a stolen session can remain useful.

Background polling deliberately does not reset the idle timer. If it did, simply leaving a dashboard open would keep a session alive indefinitely and the idle timeout would mean nothing.

Until there is a published API, the supported export paths are:

  • Reports for the formal artefacts: compliance reports, gap analysis, executive summary, audit log, PII summary, and more, all as CSV.
  • Table exports on most pages, which export the current filtered view. Filter first, then export, and the file matches what you reviewed.

Both are covered by the same guarantees: exports carry counts and metadata, never the sensitive values themselves, and compliance exports exclude hidden and stale datastores while surfacing the count of what was excluded.

The one API contract Argus already keeps is the agent’s. The platform publishes the agent versions it supports (GET /api/v1/agents/version-policy returns the minimum, the recommended version and whether the minimum is enforced yet), and a change that would break a supported agent version retires that version first: the recommended version is raised, then the minimum is set with an effective date in the future. Until that date an agent below the minimum keeps working, and the lag is recorded on the agent and notified to you; after it, the agent is refused (HTTP 426) and told why. A pinned agent is therefore never cut off by a release, only by a floor with a published date, and the deploy drawer stops offering a version the moment a floor names it. A customer-facing API, when it lands, is worth waiting for because it will carry the same guarantee.