API keys

Bearer tokens for the CLI and CI, scoped to the role of the account that created them.

Creating one

Account → API keys → create. The full key is shown once, at creation, and never again: only a hash of it is stored, so nobody — including whoever operates the deployment — can read it back out of the database.

If you lose a key, revoke it and make another. There is no recovery path, and a system that offered one would be storing the key in a form that could be stolen.

Using one

A key is a bearer token. Send it in the `Authorization` header, or let the CLI do it by setting `WEBCURIS_API_KEY`.

Keys are independent of session cookies, so a key keeps working when your browser session expires — and revoking a key does not sign you out.

curl -H "Authorization: Bearer wk_..." https://scan.example.com/api/scans

Scope, and what a key cannot do

A key carries the role of the account that created it and nothing more. A key made by a non-owner cannot reach owner-only routes, and no key can escalate its own role.

Every use updates the key's last-used timestamp, which is what tells you a key you forgot about is still in something's CI configuration. Revocation takes effect immediately, on the next request.

Contact

Talk to us.

Questions about what the engine checks, whether it fits your estate, or what it deliberately refuses to do. A person reads every message.

  1. 01You writePlain form, no qualifying call, no obligation. The marketing checkbox is optional and unticked.
  2. 02A person reads itMessages land with the team, not a queue-bot. Nothing is auto-replied.
  3. 03You get an answerTo the address you gave — including “this product is not the right fit”, when that is the honest answer.
Prefer email?
Use the form — no address is published on this deployment.
Reporting a vulnerability?
Read the disclosure policy first — it tells you what is in scope and what to expect.
New messagereplies go to your email

Personal addresses (gmail, outlook, and similar) are not accepted.

+91

0 / 4000