Praxis is the Agent Cloud Platform. The API is organized by service: agents, models, sandboxes, search, and automation, each under its own prefix. Requests and responses use JSON, streaming responses use SSE, and standard HTTP verbs and status codes apply. All prefixes share one address and one Key.

Base URL

https://api.deepraxis.com

Client libraries

Use the client libraries listed on each service's API page. Compatible APIs use official protocol SDKs. For local installation of the automation TypeScript SDK, see Automation API.

Compatible APIs

Code already using OpenAI, Anthropic, Google, E2B, or Tavily doesn't need to be rewritten for Praxis: the platform offers compatible prefixes that match those vendors' official APIs — change the address and go.

One Key

All prefixes share the API Key created in the console, sent with each request in the Authorization header. See Authentication.

Global conventions

• Errors use standard HTTP status codes for the class, with a body in the prefix's own format for the cause. See Errors.
• Exceeding a quota returns 429, and a response header tells you when to retry. See Rate limits.
• Versions live in the address; deprecations are announced 90 days ahead via standard headers. See Versioning.
• Information about the API itself (OpenAPI description, health) lives under the /meta prefix.

First request

curl https://api.deepraxis.com/model/v1/chat/completions \
  -H "Authorization: Bearer $PRAXIS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-flash", "messages": [{"role": "user", "content": "Hello"}]}'

Every endpoint uses the same credential: an API Key created in the console, sent with each request in the Authorization header. There is no other authentication method and no per-endpoint rules.

One header

Authorization: Bearer {key}

One Key works across every prefix. Keys are created, rotated, and revoked at Console → API Keys; revocation takes effect immediately.

Where each SDK puts the Key

You don't assemble the header yourself — the official SDKs do it; we also accept the header names those SDKs send by default.

Try one

curl https://api.deepraxis.com/model/v1/models \
  -H "Authorization: Bearer $PRAXIS_API_KEY"

What an auth failure looks like

A missing, invalid, or revoked Key returns 401, with a body in the format of that prefix (see Errors). Never retry a 401 — fix the Key and send again.

Safekeeping

• Use it server-side only; never ship it in a browser, mobile app, or public repository.
• Use an environment variable (PRAXIS_API_KEY in the examples), not code.
• If you suspect a leak, revoke it in the console and create a new one; the old Key stops working immediately.

When something fails, the HTTP status code tells you the class of the failure; the body gives the specific cause in the format of that prefix; and every error response also carries four x-praxis-problem-* headers plus one x-praxis-recovery-action, so retry logic only needs the headers, whatever the body looks like.

Status codes

Error codes

These are common machine-readable codes, not an exhaustive enum for every endpoint. Compatible error bodies may use protocol-specific code/type values. For cross-protocol handling, read x-praxis-problem-code, which can differ from the body code. Codes are case-sensitive.

Error body

The body format follows the first segment of the address, same as success responses — your SDK needs no special handling for errors.

Vendor prefixes (/openai /anthropic /google /e2b /tavily): identical to that vendor's official API error body.

// /openai
{ "error": { "code": 401, "message": "Invalid API key." } }

// /anthropic
{ "type": "error", "error": { "type": "authentication_error", "message": "Invalid API key." } }

Praxis prefixes (/agent /model /sandbox /search /meta): standard Problem Details (RFC 9457), Content-Type: application/problem+json.

{
  "type": "https://deepraxis.ai/problems/authentication_error",
  "title": "authentication_error",
  "status": 401,
  "detail": "Invalid API key.",
  "instance": "problem_eqfnxu",
  "code": "AUTHENTICATION_ERROR",
  "retryable": false
}

Error headers (five common + one rate-limit header)

The five common headers are independent of body format; the sixth, scope, applies to rate-limit errors:

Retrying

• retryable is true (or status 429 502 503): retry with exponential backoff; for 429 honor retry-after first.
• Everything else: never retry verbatim — fix the request or the Key first.

Praxis rate limiting has two layers: the platform layer caps requests per second and concurrent requests per Key; the model layer caps requests per minute (RPM) and tokens per minute (TPM) per model. Every response — success or 429 — carries three x-ratelimit-* headers stating your current allowance and when it resets, so you never have to guess or spend a request to check.

The two layers

Both layers return the same three rate limit headers; which layer tripped is stated in the error body (Errors).

Platform layer: requests per second and concurrency

By default, each API key allows 5 requests per second and 4 concurrent in-flight requests. Streams occupy a concurrency slot until they finish. Exceeding either limit returns 429 with ratelimit-limit, ratelimit-remaining, ratelimit-reset and retry-after; when concurrency is full, let an existing request finish.

Configured limits may differ; use the actual response headers and concurrency error details.

Three response headers

x-ratelimit-limit-requests: 5
x-ratelimit-remaining-requests: 4
x-ratelimit-reset-requests: 850ms

The same three numbers are also available under the IETF names RateLimit-Limit / RateLimit-Remaining / RateLimit-Reset (whole seconds). The default is 5 requests/second and 4 in flight; response headers reflect configured request-rate overrides.

Exceeding the per-second limit

The (N+1)th request within one second — N being the Key's per-second ceiling — is answered 429 with a retry-after header (whole seconds, usually 1). Rejected requests do not consume the allowance: x-ratelimit-remaining-requests stays 0, and the window simply resets.

Exceeding the concurrency limit

When the number of in-flight requests — including unfinished streaming responses, which hold their slot until the stream ends — exceeds the Key's concurrency ceiling, extra requests get 429 with retry-after: 1. Resetting the per-second window does not free a concurrency slot: an in-flight request must finish first. Which limit tripped is spelled out in the error message ("Concurrent request limit …" / "Requests per second limit …").

Error body

The error body follows the first path segment (see Errors). Native endpoints such as /model/v1/chat/completions return Problem Details:

{
  "type": "https://deepraxis.ai/problems/rate_limit",
  "title": "rate_limited",
  "status": 429,
  "detail": "Requests per second limit of 5 exceeded for this credential. Retry after the listed wait.",
  "instance": "problem_eqfnxu",
  "kind": "rate_limit",
  "scope": "platform",
  "retryable": true
}

scope: "platform" means the platform layer triggered it. Vendor-prefixed endpoints speak that vendor's own error format — for the OpenAI-compatible endpoints:

{ "error": { "code": 429, "type": "rate_limit_error", "message": "Requests per second limit of 5 exceeded for this credential. Retry after the listed wait." } }

Requests without a credential

Public endpoints (such as GET /model/v1/models) can be called without a Key; those are counted per source IP against a smaller anonymous allowance, with the same response headers. Sending a Key switches accounting to the Key, regardless of IP.

GET /meta/v1/health is never rate limited — point uptime monitors at it freely.

Model layer: requests and tokens per minute

The model layer counts per model × tenant × minute, not per API Key:

• Each model carries its own RPM and TPM in its model metadata; unset or 0 means unlimited.
• Hitting either limit returns 429 with type rate_limit_error, Retry-After: 60, and problem.details.rateLimit carrying the current value and the cap.
• BYOK calls bring their own provider credentials and do not count against platform model limits.
• Upstream provider rate limits are handled by automatic failover to other providers; when none remain, the upstream 429 is returned.

Models also carry a monthly budget based on cumulative revenue for the month; exceeding it returns 429 with type budget_error (QUOTA_EXHAUSTED) and no Retry-After — waiting does not help; the model's budget must be raised.

For status codes and error bodies see Errors; for account quotas see Quotas & rate limits.

The version is part of the address, immediately after the first segment; each prefix is versioned independently — there is no site-wide version number.

The version segment in the address

https://api.deepraxis.com/{protocol}/{version}/…

Under vendor prefixes, version-related headers (such as Anthropic's anthropic-version) are passed through to the vendor as-is, behaving exactly like the official API.

What counts as breaking

Removing fields, changing a field's type or meaning, changing defaults, tightening validation, changing what an error code means. Adding fields, adding endpoints, and loosening validation are not breaking.

Beta and GA

• Beta: marked "Beta" on the endpoint page. May change at any time with no compatibility promise; fine for trying out, not recommended for production.
• GA: breaking changes ship only as a new version segment (e.g. /model/v2/…); the old version keeps working.

How deprecation is announced

When an old version or endpoint is deprecated:

1. A changelog announcement, with a replacement path;
2. That endpoint's responses carry two standard headers: Deprecation (RFC 9745, when it was deprecated) and Sunset (RFC 8594, when it goes away), plus a Link header pointing to migration notes;
3. At least 90 days between announcement and shutdown; afterwards it returns 404.

Deprecation: @1767225600
Sunset: Sat, 04 Apr 2026 00:00:00 GMT
Link: </docs/changelog>; rel="deprecation"