Skip to content
VEYQON
Developers · Build & connect/API

The whole system is an API, including the agents.

No hidden admin layer and no exported CSV as an integration strategy. If the interface can do it, so can you — including registering an agent and setting the limits it works within.

REST & webhooks·Typed SDKs·Local development

What it does · 22 capabilities/01

What the surface covers.

The governing property is that there is one surface. The interface, the mobile apps, the connectors, and the agents all go through the endpoints documented here, under the same permissions.

01

REST

Every record type, with the rules that apply in the interface.

  • One endpoint per record type

    Including the ones you add yourself. A custom record type is an endpoint the moment it exists, with no extra work.

  • Filtering and field selection

    Server-side filters on any field, ordering, and selecting only the fields you need rather than fetching whole documents.

  • Cursor pagination

    Stable under concurrent writes, so a long export does not skip or repeat rows when somebody posts mid-run.

  • Same permissions

    A key sits inside the same row-level permission model as a user. There is no privileged back door with looser rules.

  • Same validation

    A document posted by API passes the same checks as one posted in the interface, including workflow state and approval limits.

  • Bulk operations

    Batched create and update with a per-row result, so one bad row does not fail the batch silently.

02

Events

Finding out when something changes, without polling.

  • Webhooks per state change

    Subscribe to document types and transitions, receiving the document, the change, and the actor.

  • Signed payloads

    Every delivery signed so the receiver can verify it came from your instance and was not replayed.

  • Retry and replay

    Automatic retry with backoff, and manual replay over a window after you have fixed a downstream outage.

  • Delivery visibility

    What was sent, what succeeded, and what is being retried, as records rather than as a support question.

03

Clients and tooling

What you write against.

  • Typed SDKs

    TypeScript and Python clients generated from the same definition the API serves, so they cannot drift from it.

  • OpenAPI definition

    Published and versioned, so you can generate a client for a language we do not ship.

  • Local development

    One command brings the whole stack up on your machine with seeded data, including the agent runtime.

  • Sandbox

    A separate instance with the same API surface, so promoting to production is a change of key and URL.

04

Extending the model

Adding your own records without leaving the platform.

  • Custom record types

    Your own types with the same permissions, workflow, versioning, and audit trail as the built-in ones.

  • Custom fields on core types

    Added without forking, so the platform still upgrades underneath them.

  • Server-side scripting

    Hooks on document events for validation and derived values, versioned as code rather than configured in a text box.

  • Apps, not patches

    Extensions are packaged apps in source control. That is the property that makes an upgrade routine instead of a project.

05

The agent API

Agents are ordinary objects here, which is the point.

  • Register and configure

    Create an agent, set its role, tools, and ceilings programmatically rather than only through the interface.

  • Read the reasoning

    Pull an agent's decisions and their inputs, so your own monitoring can watch them alongside everything else.

  • Change posture

    Move an agent between proposal and acting modes by API, which is what makes an automated kill switch possible.

  • Same limits apply

    An agent created by API is bound by the same ceilings and segregation rules as one created in the interface.

Getting started/02

From key to first call.

The whole path, and the reason there is no separate integration API to learn: sandbox and live share one surface.

  1. 01

    Key

    Issue a scoped API key from the same permission model your users sit in.

  2. 02

    Call

    Read a record, filter a ledger, or post a document. Same rules as the interface.

  3. 03

    Subscribe

    Register a webhook and receive state changes as they happen, not on a poll.

  4. 04

    Ship

    Move the key to production. Sandbox and live share one API surface.

The spec/03

The specification.

The details you would otherwise have to discover from the documentation.

Protocol
REST over HTTPS, JSON
Definition
Published, versioned OpenAPI
Auth
Scoped API keys and OAuth, inside the user permission model
Pagination
Cursor-based, stable under concurrent writes
Events
Signed webhooks with retry, replay, and delivery records
SDKs
TypeScript and Python, generated from the definition
Rate limits
Per key, with headers and documented burst behaviour
Local
Full stack including agent runtime, one command
Where it stops/04

The honest notes.

Things a developer would find out in week two, put here instead.

Rate limits are real
A bulk migration should use the batch endpoints and a backoff, not a loop over single writes. The limits are published rather than discovered.
It will not let you skip validation
There is no flag to post a document that would not be accepted in the interface. Bypassing business rules by API is not something we will add.
Custom fields are yours to maintain
They survive upgrades, but a field you add is a field you own, including its meaning three years later.
Breaking changes happen at a version
They are announced, dated, and never shipped into an existing version — but they do happen, and pretending otherwise would be worse.

Next step

Bring one process. We will run it live.