> ## Documentation Index
> Fetch the complete documentation index at: https://docs.velatir.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Velatir API

> Call Velatir's backend from your own systems with an API key.

Velatir's dashboard is a client of a public HTTP API, and your own systems can call that same API. Use it
when a rule in Velatir should follow something your business already knows — a project becoming
confidential, a supplier being onboarded, a team changing scope — instead of waiting for someone to
remember to update it by hand.

The API is reached at:

```
https://api.velatir.com
```

## Two Kinds of Key

Velatir has two key types, and they are not interchangeable. Both are created on the same settings page,
which is why it is worth being precise about which one a task needs.

|             | Ingestion key                                                                                             | API key                                                      |
| ----------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| **Prefix**  | `vltr_ingest_`                                                                                            | `vltr_api_`                                                  |
| **Purpose** | Sends activity *into* Velatir                                                                             | Reads and changes your organisation's configuration and data |
| **Used by** | Velatir for Desktop, the browser extension, connectors such as [Claude Cowork](/connectors/claude-cowork) | Your own scripts, services, and automation                   |
| **Access**  | Submits telemetry only. No access to organisation data                                                    | Administrator-equivalent across the whole organisation       |
| **Scope**   | Whole organisation, or a single workspace                                                                 | Whole organisation only                                      |

<Warning>
  An API key carries administrator-equivalent access to everything in your organisation. Anyone holding it
  can read your traces and change your agent configuration. Treat it like an administrator's password, not
  like a deployment setting: keep it in a secret store, never in source control or a browser, and revoke it
  the moment you suspect it is exposed.
</Warning>

<Note>
  If you are rolling Velatir out to people's devices, you want an **ingestion key**, not an API key. Start
  from the [quickstart](/quickstart) instead.
</Note>

## What You Can Do With an API Key

An API key reaches the organisation endpoints as an administrator. In practice that covers reading your
traces, assessments, and agents, and managing [instructions](/agents/instructions) — the main reason
customers automate against Velatir.

Some things are deliberately closed to an API key:

* **Creating keys.** Only a signed-in person can create a key, so a leaked key cannot mint itself a
  replacement or quietly widen its own foothold.
* **Submitting activity.** An API key is rejected by the ingestion endpoints, and an ingestion key is
  rejected by the organisation endpoints. Neither can stand in for the other.

<Warning>
  An API key **can** revoke keys, including your others. Revoking is an administrator action and a key
  holds administrator access. Combined with the above, a leaked key cannot create a new credential, but it
  can take your existing ones away — one more reason to keep it in a secret store and revoke it promptly if
  it is exposed.
</Warning>

Access is also all-or-nothing today. There is no way yet to issue a key that can only read, or one
limited to a single endpoint. Where that matters, issue a separate key per system so you can revoke one
without disturbing the others.

## Changes Are Attributed to the Key

Anything an API key changes is recorded against **the name you gave the key**, not against a person and
not as an anonymous system actor. A key named `roadmap-sync` produces an audit trail that reads clearly a
year later; one named `test` does not.

Give each integration its own key, named for the system that holds it.

***

<CardGroup cols={2}>
  <Card title="Authentication" icon="key-round" href="/api/authentication">
    Create a key, send it with a request, and find your organisation id.
  </Card>

  <Card title="Instructions over the API" icon="fingerprint" href="/api/instructions">
    Create, update, and remove instructions programmatically.
  </Card>
</CardGroup>
