API Overview

Complete API documentation for integrating with Cliqer

The Client API is part of the Ultra plan and up. Long-lived API keys for unattended, server-to-server access are minted on the Studio and Enterprise plans, see API Key Authentication. Compare plans.

API Reference

Complete documentation for the Cliqer API, covering REST endpoints and WebSocket realtime communication.

Base URL

https://cliqer.io/api

All API endpoints are relative to the base URL of the Cliqer server you're connecting to.

Code Examples: In curl/Python/Go examples, replace $BASE_URL with your Cliqer instance URL (e.g., https://cliqer.io). For WebSocket examples, replace $WS_URL with wss://cliqer.io. TypeScript examples use relative paths and work without modification.

Authentication

Cliqer authenticates with an httpOnly session cookie (session_token), minted by POST /api/auth/login. Browsers send it automatically; server-to-server tooling keeps it in a cookie jar. Studio and Enterprise teams can also mint API keys for server-to-server use, sent as Authorization: Bearer cliqer_<key> (key management requires the Studio or Enterprise plan).

# The session cookie is set by /api/auth/login and sent on every subsequent request
Cookie: session_token=YOUR_SESSION_TOKEN

# Or authenticate a server-to-server request with a team API key
Authorization: Bearer cliqer_<key>

A few endpoints need no session: POST /api/licenses/validate is public, and GET /api/turn-credentials is gated by an Origin allow-list rather than a session.

See Authentication for login, session rotation, and security best practices.

API Sections

Authentication

Login, session rotation, and security best practices.

WebSocket Realtime

Real-time presentation control, room management, and collaboration.

Licenses

License validation, activation, and device management.

Connections

Active connections, user management, and room broadcasting.

WebRTC

TURN/STUN credentials for peer-to-peer video streaming.

Request Lifecycle

Error Responses

All endpoints return standard error responses:

StatusDescription
400Bad Request - Missing or invalid parameters
401Unauthorized - No valid session cookie
403Forbidden - Insufficient permissions or disallowed origin
404Not Found - Resource not found
409Conflict - e.g. license activation seat limit reached
429Too Many Requests - Rate limit exceeded (see Retry-After)
500Internal Server Error

Error Response Format:

{
  "statusCode": 400,
  "statusMessage": "Description of the error"
}

Rate Limiting

Most endpoints are rate-limited per client IP at the network edge, using a fixed 60-second window across three tiers. When a request exceeds the limit the server responds 429 Too Many Requests with a Retry-After: 60 header. There is no progressive/exponential blocking, and no X-RateLimit-Remaining header is returned.

HeaderDescription
Retry-AfterSeconds until the window resets (60, sent only on a 429)

Rate Limit Tiers

TierRequests / 60sApplied to
Strict5POST /api/licenses/validate, POST /api/connections/rooms/{roomId}/close, and the sign-in endpoints (POST /api/auth/login, registration, password reset, passkey and 2FA steps)
Standard30GET /api/licenses/status, POST /api/licenses/deactivate, GET /api/connections/active, POST /api/connections/{id}/kick, POST /api/connections/rooms/{roomId}/broadcast, GET /api/auth/me, POST /api/auth/logout
Relaxed60High-volume read endpoints

Two endpoints apply a second Strict limit keyed on the credential rather than the IP, so one target cannot be hammered across many addresses: POST /api/licenses/validate keys on the license_key, and POST /api/auth/login keys on the email address. GET /api/turn-credentials is not per-IP rate-limited (it is gated by an Origin allow-list instead), but a global mint cap applies, above it the endpoint serves a cached, still-valid credential set instead of returning 429.

Exceeding a tier returns 429 for the remainder of the 60-second window. Rate limits are enforced at the network edge, before the request reaches application code.