Reference

Every endpoint, error code, permission, policy field, event type, CLI flag and environment variable.

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.

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

Conventions

Envelopes, pagination, idempotency, scope headers, correlation ids.

Authentication

Sessions, API keys and agent tokens compared.

REST API

Every endpoint, grouped, with permissions and step-up requirements.

Error codes

Every code, its status, and what to do about it.

#Generated registries

	Generated from
REST API	The API catalogue in `apps/control-plane/src/routes/developer.ts`
CLI	The command specs in `packages/cli/src/help.ts`
Error codes	`ERROR_CODES` in `packages/types/src/errors.ts`
Permissions and roles	`packages/types/src/permissions.ts`
Policy fields	`packages/policy/src/fields.ts`
Policy templates	`packages/policy/src/templates.ts`
Event types	`packages/types/src/events.ts`
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:

#For a coding agent

Every page is available as plain Markdown at /_llms/<slug>.md, and the whole site is indexed at 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.