API and automation surfaces

Cryptographic inventory is only useful if it reaches the systems that already run your change process. Nobody is going to open a console to check whether a certificate is quantum-vulnerable before a release. This page describes Continuum, the programmatic surface we are building for exactly that, and it is explicit about what does not exist yet.

#What the surface is for

Continuum is designed around three jobs. Everything else is deliberately out of scope, because an API that tries to mirror every console action becomes a second product to maintain and a second surface to secure.

Read the inventory

List discovered cryptographic assets in a workspace with their algorithm, key length, protocol context, first-seen and last-seen timestamps, and current risk tier. Filterable and paginated. This is what a CMDB reconciliation job or an internal dashboard consumes.

Read findings

List findings with their severity, the detector that raised them, the explanation behind the classification, and their current disposition. This is what a ticketing integration consumes to open and close work.

Export

Request a point-in-time export — findings, evidence, or a CBOM in the formats described in Cryptographic bills of material. Exports are asynchronous: you request one, you are told when it is ready, you fetch it.

Trigger a run

Start a discovery run against an already-configured scope, and poll or receive a webhook when it completes. Triggering a run does not let you change what is in scope. Scope stays a deliberate, logged, human action.

#Authentication with scoped credentials

Continuum authenticates with bearer credentials issued per workspace, never per organisation. A credential carries an explicit scope list and cannot be broadened after issue. If a consumer needs more, you issue a new credential and retire the old one.

• One credential per consumer. A pipeline, a reconciliation job and a dashboard are three consumers and three credentials. Shared credentials cannot be revoked without collateral damage, and the activity log cannot tell you which system misbehaved.
• Read scopes and action scopes are separate. A credential that can list assets does not thereby gain the ability to trigger a run.
• A credential never exceeds the granting role. An administrator cannot mint a credential with capabilities the platform does not offer to any role, and a credential issued for one workspace is meaningless against another.
• The secret is shown once. We store a verifier, not the secret. A lost secret is rotated, not recovered.
• Expiry is mandatory. Every credential carries an expiry date. A long expiry is a weak control; no expiry is not a control at all.

The illustration below is shape only. The host is a placeholder, the token is obviously fake, and neither resolves.

# Illustrative only. Continuum is not generally available.
# Both values below are placeholders — this call does not resolve.
export CONTINUUM_BASE="[PLACEHOLDER: exact API base URL]"
export CONTINUUM_TOKEN="tq_example_NOT_A_REAL_TOKEN_0000"

curl -sS "$CONTINUUM_BASE/v1/workspaces/WORKSPACE_ID/assets?tier=high&limit=100" \
  -H "Authorization: Bearer $CONTINUUM_TOKEN" \
  -H "Accept: application/json"

#Rotation and revocation

Rotation is the operation that gets skipped because it risks an outage, so it needs to be possible without one. The model is overlapping validity: issue the replacement, deploy it, confirm traffic has moved, then revoke the predecessor.

1. 1

   Issue the replacement

   A second credential with the identical scope list. Both are valid at once, which is what makes a clean cutover possible.

2. 2

   Deploy and confirm

   Roll the new secret through your secret store and confirm the consumer is using it. Per-credential usage timestamps are what you check here, not a guess.

3. 3

   Revoke the predecessor

   Revocation is immediate and irreversible. In-flight requests carrying the revoked credential are rejected rather than drained.

4. 4

   Record it

   Issue, rotation and revocation are all written to the activity log with the acting administrator. This is the trail an assessor follows.

#Rate limits, idempotency and errors

Discovery runs are expensive and touch your infrastructure, so the intended limits are asymmetric: reads are generous, actions are not. A limit exists to protect your estate from a retry loop as much as to protect us.

• Idempotency. Any request that changes state accepts a client-supplied idempotency key. Replaying the same key returns the original outcome rather than starting a second run. Generate one key per logical intent, not one per retry.
• Pagination. Cursor-based, not offset-based. An inventory that changes underneath a long scan should not silently skip or duplicate assets.
• Errors. A machine-readable error code plus a human-readable message. Client errors are 4xx and will not succeed on retry; 5xx and 429 are safe to retry with backoff and the same idempotency key.
• Versioning. A version segment in the path. A breaking change means a new version, not a surprise on a Tuesday. Deprecations are announced on Signal Log.

#Webhook delivery

Polling an inventory for change is wasteful and slow. Webhooks are the intended mechanism for anything time-sensitive: a run completing, an export becoming available, a new high-tier finding appearing.

Transport

HTTPS POST to an endpoint you nominate. HTTP is refused. One subscription may select which event classes it receives.

Signature

Every delivery carries an HMAC-SHA256 signature over the raw request body, keyed on a signing secret unique to that subscription, alongside a timestamp. Verify before you parse, compare in constant time, and reject a stale timestamp to blunt replay. Never trust an unverified body.

Retries

A non-2xx response or a timeout is retried with exponential backoff over a bounded window. After the window closes the subscription is marked unhealthy and the workspace administrators are notified. [PLACEHOLDER: webhook retry schedule and failure threshold]

Delivery semantics

At-least-once. A retry can deliver an event you have already processed. Every event carries a stable event identifier — treat it as your deduplication key and make your handler idempotent.

Ordering

Not guaranteed. Events carry a timestamp and a sequence within a run; order on those rather than on arrival.

Payload contents

Identifiers, event type, timestamps and severity. Findings themselves are fetched over the read surface rather than embedded, so that a webhook endpoint compromise does not become an inventory disclosure.