Praxsuite

Overview

Vincent Depassier · September 17, 2026

Every Praxsuite workspace has an API. You do not build it and you do not deploy it — it exists the moment the workspace does, and it exposes that workspace's tables, files, end users and custom endpoints over HTTPS.

This section is the per-endpoint reference: method, path, headers, request body, responses, errors. For why a feature exists and how to configure it from the interface, read the API Gateway section of the documentation; this reference assumes you already have a credential and want the exact shape of the call.

Base URL

https://gateway.praxsuite.com/{workspaceId}

{workspaceId} is the GUID of your workspace, visible in the URL of the interface and in API Gateway → Settings. Every path in this reference is relative to that base.

A dedicated deployment answers on its own host instead — https://gateway.<your-domain> — and that host is the one shown in API Gateway → Settings for that workspace. Read it there rather than assuming; everything else in this reference is identical.

The same routes are also reachable under an /api/v1/gateway prefix on the platform host, which is what you will see in older examples. Same endpoints, same bodies.

What the API is made of

Area

What it is for

Data

Read and write table rows with PraxQL, and introspect the schema

Files

Upload, list, download and delete blobs in the workspace

End-user authentication

Register and sign in the users of your application, not of Praxsuite

Custom endpoints

Public URLs you define that run an Automation

MCP

The same workspace exposed as tools to an AI client

Players

Identity for game platforms, where the player already has an account elsewhere

Discovery

Machine-readable descriptions of the above

Conventions

Requests and responses are JSON, and Content-Type: application/json is expected on every request with a body. File uploads are the one exception; they are multipart/form-data.

Identifiers are GUIDs. Tables, columns, rows, blobs and end users are all addressed by GUID, never by name — a name can change without breaking anything precisely because nothing addresses it.

Times are UTC in ISO 8601.

Three response shapes

Different parts of the gateway wrap their answers differently, and it is worth knowing which one you are looking at before writing a parser. The HTTP status is reliable in all three.

POST /query — and only /query — uses a structured error envelope with a stable machine-readable code:

{ "error": { "code": "SCOPE_VIOLATION", "message": "...", "details": ["..."] } }

Most of /auth/* returns a service envelope, on success and on failure alike:

{ "isSuccess": true, "statusCode": 200, "message": null, "data": { }, "errors": [] }

Everything else — the authentication layer, files, schema, endpoints — returns a flat string:

{ "error": "Invalid API key." }

See Errors and limits.

Next

  • Authentication — the two kinds of key, and who may call what

  • Errors and limits — status codes, error codes, quotas, caching

  • Query — POST /query