Verentis

Calling the API

Calling the Verentis API

Make authorised requests through the API gateway — base URLs, versioning, bearer auth, and response shape.

All Verentis APIs are reached through a single API gateway at api.<domain>. You send your scoped access token as a bearer token; the gateway routes the request to the right backend service.

Base URL

EnvironmentAPI base
Local (Aspire)https://api.localtest.me:6500
Sprinthttps://api.sprint-1.verentis.dev
UAThttps://api.uat.verentis.dev
Production (region)https://api.nz.verentis.io

Never call a backend service directly — always go through the gateway.

Versioned routes

Endpoints are versioned in the path:

/v{version}/{resource}

For example /v1/workspaces or /v1/engines. Use the version documented for the endpoint you're calling.

Bearer authentication

Send the access token in the Authorization header:

GET /v1/workspaces HTTP/1.1
Host: api.localtest.me
Authorization: Bearer <access-token>
Accept: application/json
curl https://api.localtest.me/v1/workspaces \
  -H "Authorization: Bearer $TOKEN"

The token must carry the scope the endpoint requires (e.g. account.workspace.read). A token missing the scope is rejected — see Scopes & permissions.

Responses

Successful responses return JSON. List endpoints are paged and accept pageNo, pageSize and orderBy query parameters:

GET /v1/workspaces?pageNo=1&pageSize=20&orderBy=name HTTP/1.1
Authorization: Bearer <access-token>

A paged response includes the items plus paging metadata (total count, page number/size) so you can iterate.

Errors

StatusMeaning
401 UnauthorizedMissing/expired token — re-acquire and retry.
403 ForbiddenToken lacks the required scope, or no grant for the resource.
404 Not FoundResource doesn't exist (or you can't see it).
400 Bad RequestValidation failure — the body explains which field.

Prefer the SDK

In an app, prefer the SDK bridge over hand-built requests — it manages tokens and base URLs for you. Use raw HTTP for standalone tools and engines where the SDK isn't available.

Calling the API from the CLI

The Verentis CLI wraps the common surface (workspaces, users, API keys, files, executions, marketplace) in typed commands, and exposes everything else through an authenticated escape hatch — it signs in (device flow), mints the right access token per request, binds it to a workspace when needed, and renders errors for you:

verentis login     # device sign-in — approve in any browser (targets production by default)

verentis workspace list --json
verentis files ls /scripts --workspace <id>
verentis exec logs <executionId> --follow             # SSE log streaming

# Any endpoint, with automatic auth (like `gh api`):
verentis api GET /v1/engines --scope execution.execution.run
verentis api POST /v1/installations --workspace <id> --body @install.json \
  --scope marketplace.install.create --scope node.node.create

Next

Working with files & nodes

The endpoints your extensions use most.