Skip to main content
Status: Production partner preview — minimal personal-tenant durable tasks, run reads, SSE, cancellation requests, usage readback, automatic signed webhooks, and bearer webhook management are live. Exact browser approval remains pending. The developer portal’s email-link/OTP fragment callback, persisted browser session, and durable legal gate are deployed. Cancellation final-status behavior and authenticated canonical-host, alias, and deep-link preservation remain pending separate canaries. Contact us for access.
This page defines the vocabulary of the fabric: runs, events, approvals, policies, receipts, tenants, keys, and how billing works.

​
Runs

A run starts when you call POST /v1/execute with mode: "task". The call returns a run id immediately, and the run keeps going in the background. Today you track it by reading its state, resuming SSE, or receiving automatic signed webhooks. The production preview implements only minimal personal-tenant task execution. mode: "turn" returns 400 invalid_request, /v1/chat is not routed, and request-level overrides and organization delegation stay closed. Exact recorded browser-action approval is source-ready and pending activation; unsupported or unverifiable approval requests stay fail-closed. Once a run exists, these endpoints operate on it:

​
Events

Durable task events carry apiVersion, run_id, a strictly increasing sequence, and an at timestamp. The current projector emits:
  • run.accepted, run.started, and run.progress for non-terminal lifecycle updates;
  • source-ready approval.required and approval.resolved events for exact recorded browser actions;
  • exactly one terminal run.completed, run.failed, or run.cancelled event.
The source repository contains richer candidate turn event schemas for offline contract work. They are unserved and do not add a public route or SDK method. For mode: "task" runs, GET /v1/runs/:id/events is resumable: reconnect with a Last-Event-ID header and the stream picks up where it left off.

​
Approvals: digest-bound resume

After the source-ready browser-action refinement is activated, an exact stored browser step can pause and emit approval.required with its canonical summary and action_digest. Show the summary unchanged to a person, then call:
decision is approve or deny. The digest has to match the paused action exactly. A changed argument, an expired approval, a replayed approval, or an approval posted against the wrong run is rejected. This is the same fail-closed pattern the rest of Praxa’s approval surfaces use: what is shown to the approver is exactly what gets checked before anything runs.

​
Policies

Praxa’s current product domains already apply fail-closed approval and billing checks before consequential work. The planned unified policy engine will combine these inputs:
  • the tool’s capability metadata (read-only, destructive, human-in-the-loop),
  • the kind of effect the action has,
  • any monetary threshold involved,
  • whether the category is sensitive,
  • how the action compares to the tenant’s history,
  • the tenant’s policy pack,
  • and any standing grants already in place.
The planned engine returns auto, peer_review, human_approval, or deny, plus a TTL and approver requirements. Configurable policy packs and public policy-version receipts are not active in the partner preview. The shared request schema reserves a policy field for a risk ceiling, budget cap, model lane, tool allowlist, and approval mode. The current handler rejects that whole override before task creation.

​
Receipts

The current run and event resources are narrow customer-safe projections, not mature receipts. The target receipt records what ran, which policy version applied, who approved which digest, and how the outcome was verified. Mature receipts, the hash-chained evidence ledger, and PDF/SIEM export remain on the build list.

​
Tenants and keys

The live public tenant is owned by one personal account. The broader target model can also represent organizations, but organization execution, keys, and billing ownership are unavailable. A personal tenant can hold multiple API keys with endpoint scopes, expiry, last-used metadata, and revocation state. Keys are SHA-256 hashed at rest; Praxa never displays the raw key after its one-time create/rotate response. A stable dedicated per-key rate-tier product is not yet documented or available. There are three credential families on the same gateway:
  1. Supabase-authenticated sessions: the Praxa mobile app and Praxa Control desktop app authenticate this way.
  2. Custom-agent deployment keys: the credential family behind today’s live custom-agent API and embeds. These keep working as they do today.
  3. praxa_sk_* platform API keys: the new fabric tenant model described on this page.
Each active surface derives authority server-side and fail closed. Do not infer that a Supabase session or custom-agent credential can call /v1, or that a praxa_sk_ credential gains custom-agent authority.

​
Billing: bundled vs. BYO

Bundled inference is the active funding path. BYO provider funding is planned and not available in the partner preview. Bundled runs spend Praxa credits and use immutable reservation economics. The BYO column describes the intended contract, not an option you can enable today.
Last modified on August 14, 2026