This page provides a quick, actionable path to authenticate, call REST endpoints, and capture streaming events from the middleware.
API Structure
The Praxis AI API is organized into three functional areas:Authenticate
Sign in or authenticate to retrieve an access token.
Runtime
Endpoints for selecting a Digital Twin, creating conversations, developing assistants, and dialoguing with AI models.
Administration
Configure Digital Twins, set up permissions and entitlements, audit user history, and monitor activity.
Getting Started
Obtain an authorization token
All API requests require an authorization token issued after successful authentication. See the Authentication API for how to sign in and use the token in requests.
Know your Base URLs
- REST API base:
https://pria.praxislxp.com/api - Socket.IO middleware (stream events):
https://pria.praxislxp.com/socket.io
Using the API
The Praxis API follows standard RESTful conventions:- JSON for all requests and responses
- HTTP status codes communicate success/failure
- Error responses return a consistent JSON shape with details
- Rate limits protect service stability
If you’re building a browser client, ensure you include the correct auth header on every request. Authorization tokens are only valid for 24 hours.
Automating with the Live API Definition
Both APIs publish a live OpenAPI 3 (Swagger) definition that always reflects the currently deployed endpoints, schemas, parameters, and auth schemes. These are the exact specs that power this API Reference — fetching them programmatically gives you a machine-readable contract you can hand to code generators, AI coding agents, and orchestration platforms.| API | Live OpenAPI definition |
|---|---|
| Runtime API | https://pria.praxislxp.com/api/rt-docs.json |
| Administrator API | https://pria.praxislxp.com/api/admin-docs.json |
Because these URLs serve the live definition, anything you generate from them stays aligned with the deployed API — re-fetch after a Praxis AI release to pick up new endpoints and fields automatically.
Why use the live definition
- Always current — no hand-maintained endpoint lists to drift out of date.
- Machine-readable — standard OpenAPI 3 JSON that virtually every tool and agent understands.
- Self-describing — request/response schemas, required parameters, and auth schemes are all encoded, so tools can scaffold correct calls without guesswork.
Use it with AI coding agents (Claude, Claude Code)
AI coding assistants such as Claude and Claude Code can consume the OpenAPI definition directly to scaffold typed clients, write request code, or build an MCP server that exposes Pria endpoints as tools.Point the agent at it
Give the agent the file (or the live URL) and describe what you want. For example:
“Usingpria-runtime-openapi.json, generate a typed TypeScript client for the Q&A and conversation endpoints, withx-access-tokenauth wired in.”
“From this OpenAPI spec, build an MCP server that exposes the Runtime API as tools so I can call Pria from my agent.”
Wire in authentication
The spec describes the auth scheme, but the agent still needs a valid token. Supply one from the Authentication API and have the agent attach it as the
x-access-token header.Import into orchestration platforms
Low-code/iPaaS tools, API clients, and agent frameworks accept an OpenAPI URL or file to auto-generate connectors — no manual endpoint mapping required:| Tool / platform | How to import |
|---|---|
| Postman / Insomnia | Import → Link and paste the definition URL to generate a ready-to-run request collection. |
| n8n / Make / Zapier | Use their HTTP/OpenAPI or custom-connector import to register Pria operations. |
| LangChain / LlamaIndex | Load the spec with an OpenAPI toolkit to expose endpoints as agent tools. |
| openapi-generator / swagger-codegen | Generate typed client libraries in 50+ languages. |
HTTP Streaming with Server-Sent Events (SSE)
Praxis AI offers a pure HTTP streaming endpoint using Server-Sent Events (SSE). This approach is ideal for:- Server-side applications (Node.js, Python, Go, etc.)
- Automation, agents, and orchestration tools
- Environments where WebSockets are restricted
- Simpler integrations without persistent socket connections
- SDK and CLI tool development
The SSE streaming endpoint uses the same JWT authentication as other REST endpoints. No Socket.IO connection is required.
Endpoint
Request Headers
| Header | Required | Description |
|---|---|---|
x-access-token | Yes | Your JWT authentication token |
Content-Type | Yes | application/json |
Request Body
| Field | Type | Required | Description |
|---|---|---|---|
inputs | string[] | Yes | User messages to send to the AI |
requestArgs.institutionPublicId | string (UUID) | No | Specifies the digital twin (institution) to send the command to. Validates user membership and switches the user’s active institution for the request. |
requestArgs.assistantId | string (ObjectId) | No | Assistant to use. Takes priority over selectedCourse.assistant._id (legacy). Falls back to history record resolution. |
requestArgs.selectedCourse | object | No | Conversation context with course_id and course_name |
requestArgs.ragOnly | boolean | No | When true, returns only RAG search results without AI generation |
requestArgs.userTimezone | string | No | User’s IANA timezone identifier |
cURL Example
Response Headers
Response Format
The endpoint returnstext/event-stream; charset=utf-8 content type with SSE-formatted JSON chunks. Each line is prefixed with data: followed by a JSON object and two newlines.
| Event Type | Description | Key Fields |
|---|---|---|
connected | Stream established | message |
stream | AI-generated text chunk | prompt (cumulative), delta (incremental) |
thinking | Model reasoning / chain-of-thought (where the provider exposes it) | id (round-N), round, delta (new chars) on intermediate frames; text, done: true, optional signature on round close |
tool_call | Tool invocation started (RAG, web search, etc.) | call_id, name, arguments, displayInfo |
tool_result | Tool execution completed with results | call_id, name, response, success, responseDurationMs |
complete | Final response with usage metrics | success, usage, outputs, model, cached, completion |
error | Processing error | error.message, error.status |
done | Stream terminated — no more events will follow | (none) |
The
prompt field on stream events is cumulative (full response up to this point); the delta field contains only the new characters since the last event. Use delta for incremental UI rendering and prompt for the current full text.thinking events are gated by an institution-level Display Thinking Details toggle (default on). When disabled, no thinking events fire and the underlying History record stores no thinking text. Personal users (no institution) always receive thinking events. Providers that do not expose thinking (Mistral) simply emit no thinking events. OpenAI emits summary-only thinking — OpenAI hides raw chain-of-thought by policy.Thinking is collected per tool round — each round of model output before/after a tool call gets its own entry, keyed by
id (round-0, round-1, …). Intermediate frames within a round are append-only deltas; the round closes with a single done: true frame carrying the authoritative full text and (for Anthropic / Bedrock) a signature used for provider-side multi-step continuation.Node.js Client Example
Using Fetch API (Browser/Node.js 18+)
Cancelling an HTTP Stream
To cancel an in-flight HTTP stream request, you can abort the fetch request:Comparing Socket.IO vs HTTP SSE
| Feature | Socket.IO | HTTP SSE |
|---|---|---|
| Connection type | Persistent WebSocket | Per-request HTTP |
| Setup complexity | Higher (connection management) | Lower (standard HTTP) |
| Bidirectional | Yes | No (server → client only) |
| Cancel mid-stream | cancel_request event | Abort controller |
| Best for | Real-time apps, browsers | APIs, CLIs, serverless |
| Proxy compatibility | May require configuration | Works everywhere |
Streaming with Socket.IO
Socket.IO is an alternative to the HTTP SSE method above. Prefer it when you need a persistent, bidirectional real-time connection — for example, an interactive browser client. For automation, SDKs, CLIs, and most server-side integrations, use SSE instead.
1 Install the Socket.IO Client
2 Connect and register your user
3 Listen for streaming and diagnostic events
payload received from the stream
Note that the final response may differ from the
prompt returned while streaming.Event types
AllRECEIVE_STREAM payloads carry a type field. Branch on it to handle each kind:
type | When fired | Key fields |
|---|---|---|
STREAM | Incremental assistant text | prompt (cumulative), delta (new chars) |
THINKING | Model reasoning / chain-of-thought (where the provider exposes it) | id (round-N), round, delta (new chars) on intermediate frames; text, done: true, optional signature on round close |
TOOL_CALL | Tool invocation started (RAG, web search, MCP, etc.) | call_id, name, arguments, displayInfo |
TOOL_PROGRESS | Long-running tool emits a status update | call_id, displayInfo, optional progress (0–1) |
TOOL_RESULT | Tool execution completed | call_id, name, response, success, responseDurationMs |
RELOAD | New conversation turn started (clears prior turn’s UI state) | (none) |
THINKING — model reasoning stream
THINKING events surface the model’s internal reasoning text (a.k.a. chain-of-thought / “thinking” mode) for the providers that expose it: Anthropic, AWS Bedrock, Google Gemini, OpenAI (summary only — OpenAI hides raw chain-of-thought by policy), and xAI. Mistral does not expose thinking at all and emits no THINKING events.
Thinking is collected per tool round — each round of model output before/after a tool call gets its own entry, keyed by id of the form round-0, round-1, etc. Frames within a round are append-only deltas; the round closes with a single done: true frame carrying the authoritative full text and (for Anthropic / Bedrock) a signature for provider-side continuation.
The
THINKING stream is gated by an institution-level Display Thinking Details toggle (default on). When the institution disables the toggle, no THINKING events fire and the underlying History record stores no thinking text. Personal users (no institution) always receive thinking events.4 Include socketId in your Q&A API requests
The server requires the active Socket.IO session ID to stream chunks to your client. IncludesocketId in requestArgs.
5 Manage reconnections
When the QANDA request response includes"streamingFailed": true, it indicates that the middleware has lost the backend Socket ID mapping (user email to client socket ID), preventing it from communicating response chunks back to the client. This typically occurs when multiple browser windows or tabs are open for the same user email, causing them to compete for the same backend session and overwriting each other’s socket registrations. To resolve this issue, you can re-establish the socket connection to re-register the most current client handle and restore proper communication between the middleware and the active client session.
6 Abort requests
To abort a request while executing, emit acancel_request event:
The
cancel_request message signals the controller API to interrupt the ongoing communication and attempt a graceful termination of the conversation. While the controller works to terminate resources cleanly, there may be a slight delay before the process completes. You will only be charged for any partial response generated up to the point of cancellation.7 Stop streaming the current request
To stop streaming the current response without aborting the request itself, emit acancel_streaming event:
cancel_streaming applies only to the current response stream and is cleared automatically before the next interaction.API vs SDK
While the API provides direct access to all capabilities, the TypeScript/JavaScript SDK simplifies most tasks.API Benefits
• Direct access to all Praxis features
• Language-agnostic integration
• Fine-grained request/response control
• Ideal for custom platforms or gateways, mobile applications
• Language-agnostic integration
• Fine-grained request/response control
• Ideal for custom platforms or gateways, mobile applications
SDK Benefits
• Higher-level abstractions
• Seamless SSO authentication • UI Ready to use
• Supports LMS Such as Canvas, Moodle, D2L, LTI
• Seamless SSO authentication • UI Ready to use
• Supports LMS Such as Canvas, Moodle, D2L, LTI
Error Handling
The API uses standard HTTP status codes:- 2xx: Success
- 4xx: Client error (invalid request, missing parameters, unauthorized)
- 5xx: Server error
Next Steps
Explore endpoint-specific docs:Authentication
How to authenticate requests and attach tokens.
AI Q&A
Send conversation requests and receive streaming responses.
SSE Streaming
Stream AI responses over HTTP using Server-Sent Events.