Introducción

Vincent Depassier · 17 de septiembre de 2026

Todo workspace de Praxsuite tiene una API. No la construyes ni la despliegas: existe desde el momento en que existe el workspace, y expone sus tablas, archivos, usuarios finales y endpoints personalizados sobre HTTPS.

Esta sección es la referencia endpoint por endpoint: método, ruta, cabeceras, cuerpo, respuestas y errores. Para el porqué de cada función y cómo configurarla desde la interfaz, lee la sección API Gateway de la documentación; aquí se asume que ya tienes una credencial y quieres la forma exacta de la llamada.

URL base

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

{workspaceId} es el GUID de tu workspace, visible en la URL de la interfaz y en API Gateway → Configuración. Toda ruta de esta referencia es relativa a esa base.

Un despliegue dedicado responde en su propio host —https://gateway.<tu-dominio>— y ese host es el que aparece en API Gateway → Configuración para ese workspace. Léelo ahí en vez de asumirlo; todo lo demás de esta referencia es idéntico.

Las mismas rutas también responden bajo el prefijo /api/v1/gateway en el host de la plataforma, que es lo que verás en ejemplos viejos. Mismos endpoints, mismos cuerpos.

De qué está hecha la API

Área	Para qué sirve
Datos	Leer y escribir filas con PraxQL, e introspeccionar el esquema
Archivos	Subir, listar, descargar y borrar blobs del workspace
Autenticación de usuarios finales	Registrar e iniciar sesión a los usuarios de tu aplicación, no de Praxsuite
Endpoints personalizados	URLs públicas que defines tú y que ejecutan una Automatización
MCP	El mismo workspace expuesto como herramientas a un cliente de IA
Players	Identidad para plataformas de juego, donde el jugador ya tiene cuenta en otro lado
Discovery	Descripciones legibles por máquina de todo lo anterior

Convenciones

Los pedidos y las respuestas son JSON, y se espera Content-Type: application/json en todo pedido con cuerpo. La subida de archivos es la única excepción: va como multipart/form-data.

Los identificadores son GUID. Tablas, columnas, filas, blobs y usuarios finales se direccionan siempre por GUID, nunca por nombre — un nombre puede cambiar sin romper nada justamente porque nada lo usa para direccionar.

Las fechas son UTC en ISO 8601.

Tres formas de respuesta

Distintas partes del gateway envuelven sus respuestas de manera distinta, y conviene saber cuál estás mirando antes de escribir un parser. El estado HTTP es confiable en las tres.

POST /query —y sólo /query— usa un sobre estructurado con un code estable, pensado para que lo lea una máquina:

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

Casi todo /auth/* devuelve un sobre de servicio, tanto en éxito como en error:

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

Todo lo demás —la capa de autenticación, archivos, esquema, endpoints— devuelve un texto plano:

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

Ver Errores y límites.

Seguir

Autenticación — los dos tipos de clave, y quién puede llamar a qué
Errores y límites — códigos, cuotas, caché
Query — POST /query