REST API

The Tektii platform is backed by a versioned REST API at https://api.tektii.com. The CLI and MCP server are the recommended way to drive it, but the /v1 REST surface is a first-class contract you can call directly — handy for tight polling loops (e.g. waiting on a scenario to finish) or wiring Tektii into your own tooling.

Base URL

All requests go to the versioned /v1 prefix on the production host:

https://api.tektii.com/v1

For example, fetching a scenario:

GET https://api.tektii.com/v1/scenarios/{scenario_id}

Authentication

Authenticated endpoints require your API key in the X-API-Key request header:

curl https://api.tektii.com/v1/strategies \
  -H "X-API-Key: your-api-key"

The same key the CLI uses (TEKTII_API_KEY) works here — see CLI Authentication for how the CLI reads it.

Getting an API key

API keys are minted in the web app:

1. Log in to your Tektii account
2. Go to Developers → API Keys
3. Click Create New Key and copy it — it is shown only once

Only the read-only reference endpoints are public and need no key: the instruments catalog (GET /v1/instruments and its sub-paths) and GET /v1/templates. Every other endpoint requires the X-API-Key header.

Supported endpoints

These are the public, supported endpoints. Path parameters are shown in {braces}.

Strategies

Strategy versions

Versions are immutable once created — an evicted image is gone for good; upload a new version rather than expecting to restore one.

Scenarios

A scenario is one backtest run of a strategy version against a configuration.

The lightweight GET /v1/scenarios/{scenario_id} is the endpoint to poll while a backtest runs. Watch the response's state field: keep polling while it is QUEUED, PENDING, or RUNNING, and stop once it reaches a terminal state — COMPLETE, FAILED, or CANCELLED. When a run ends FAILED, the errorType field tells you where the fault lies: strategy means your strategy code raised the error (fix and re-run), platform means an infrastructure fault (safe to retry).

Scenario configurations

Reusable configuration objects (instrument, date window, costs, etc.) you can attach to scenarios.

See Scenario Configuration for the config body schema.

Reference (read-only)

See Available Instruments for the instrument response schema and symbol formats.

Errors

Every error response uses the same envelope — an error object with a machine-readable code, a human message, and optional details:

{
  "error": {
    "code": "NOT_FOUND",
    "message": "scenario not found",
    "details": null
  }
}

details is an optional string (present only for a few codes, e.g. a serialized report); it is omitted when there's nothing to add. Branch on code, never on message — messages may be reworded, codes are stable.

Stable error codes

SERVICE_UNAVAILABLE is the only retryable code here — retry with exponential backoff. Everything else is terminal; surface it to the caller.

Stability

The /v1 surface is a committed contract, with a deliberately modest guarantee:

• Additive. New fields and new endpoints may appear within /v1 without a version bump — write clients that ignore unknown fields.
• Breaking changes ship under a new version path. A backwards-incompatible change lands under a new prefix (e.g. /v2), never as a silent change to /v1.
• The published OpenAPI spec is the contract. GET /v1/openapi.json publishes the exact /v1 shape as a machine-readable OpenAPI 3.1 document — openapi.json is the source of truth, not this page.
• No formal deprecation-window SLA yet. We don't publish a guaranteed deprecation timeline. Treat the additive rule as the promise; watch release notes for anything larger.

The endpoint tables on this page track the supported surface.

Related

• CLI Overview — the recommended, higher-level way to drive the platform
• CLI Authentication — how the CLI reads your API key
• Available Instruments — the public instruments endpoint
• Scenario Configuration — the configuration body schema