---
title: Reference
description: Every endpoint, error code, permission, policy field, event type, CLI flag and environment variable.
label: Overview
---

Most of this section is **generated from the product's own registries** at build
time — the API catalogue the console reads, the error table the HTTP layer
throws from, the permission list RBAC is computed from, the policy field
descriptors the visual builder renders, the CLI command specs `--help` prints.

:::check Generated pages cannot drift
Add an endpoint and its row appears on the next build. Delete an error code and
its row disappears. Add an API group without writing an explanation for it and
**the build fails**.

That last one is the point: a new API surface has to be explained, not just
listed.
:::

## Start with these

:::cards

:::card Conventions | /reference/conventions | ≡
Envelopes, pagination, idempotency, scope headers, correlation ids.
:::

:::card Authentication | /reference/authentication | ⚿
Sessions, API keys and agent tokens compared.
:::

:::card REST API | /reference/api | ⇄
Every endpoint, grouped, with permissions and step-up requirements.
:::

:::card Error codes | /reference/errors | ⚠
Every code, its status, and what to do about it.
:::

:::

## Generated registries

| | Generated from |
| --- | --- |
| [REST API](/reference/api) | The API catalogue in `apps/control-plane/src/routes/developer.ts` |
| [CLI](/reference/cli) | The command specs in `packages/cli/src/help.ts` |
| [Error codes](/reference/errors) | `ERROR_CODES` in `packages/types/src/errors.ts` |
| [Permissions and roles](/reference/permissions) | `packages/types/src/permissions.ts` |
| [Policy fields](/reference/policy-fields) | `packages/policy/src/fields.ts` |
| [Policy templates](/reference/policy-templates) | `packages/policy/src/templates.ts` |
| [Event types](/reference/events) | `packages/types/src/events.ts` |
| [Configuration](/reference/configuration) | `.env.example` |

## Read it from the running system

Four endpoints give you the same information from the deployment you are
actually talking to. The first three need no authentication.

```bash
# Version, environment, both public URLs, capability and exclusion lists
curl -s https://veefore.example.com/v1/meta/info

# Every error code with its status and message
curl -s https://veefore.example.com/v1/meta/error-codes

# Every event type, and which are webhook-subscribable
curl -s https://veefore.example.com/v1/meta/event-types

# The platform verification key and the exact audience to sign for
curl -s https://gateway.veefore.example.com/.well-known/veefore-platform-key
```

Authenticated, and the source of the API reference here:

```bash
# Every endpoint, with whether *your* session can call it
curl -s https://veefore.example.com/v1/developer/api-catalog \
  -H "Authorization: Bearer $VEEFORE_API_KEY"

# Fields, operators and decisions for the Policy Builder
curl -s https://veefore.example.com/v1/policies/builder-schema \
  -H "Authorization: Bearer $VEEFORE_API_KEY"
```

The API catalogue response marks each endpoint `allowed` or not for your
session, and lists the missing permissions. That is what API Explorer in the
console renders, and it is the fastest way to find out *why* something is
refused.

## SDK references

The SDK pages live under Build, because they are as much a guide as a reference:

- [TypeScript SDK](/build/javascript-sdk)
- [Python SDK](/build/python-sdk)
- [The wire protocol, with no SDK](/build/sign-your-own-assertion)

## For a coding agent

Every page is available as plain Markdown at `/_llms/<slug>.md`, and the whole
site is indexed at [llms.txt](/llms.txt) with a description per page.

Point an agent at `llms.txt` rather than at the rendered HTML — it gets the
structure and the prose without the layout.