Autologyx Docs

Appearance

🔌 Catalyst WebSockets API ​

Welcome to the Catalyst WebSockets API reference.

This section documents the WebSocket-based APIs used to deliver real-time updates in Catalyst. These APIs are designed to provide immediate visibility into changes so that updates to rows, cells, and record counts can be reflected without requiring a page refresh.

The connection is secured using the wss protocol and requires authentication.

Authentication is based on a UUID v4 value generated by the Catalyst API endpoint:

Example connection string:

text
wss://catalyst.autologyx.com/ws/events/object-records/?uuid=eyJhbGciOi

INFO

A related technical design is available here: Real time updates Technical Design

📚 What this section covers ​

This section provides technical reference material for WebSocket endpoints that broadcast real-time Catalyst updates to connected clients.

Use these pages when you need to understand:

  • how WebSocket authentication works
  • how the connection is established
  • what type of events are broadcast
  • how batching, buffering, and reconnection behaviour work

🧩 General overview ​

Each endpoint broadcasts updates for up to 1,000 items every 5 seconds.

If the message_limit of 1,000 events is exceeded, the remaining events are stored in a buffer and included in the next WebSocket response when either:

  • the next message_time interval is reached, or
  • another message_limit threshold is triggered

If there are any events stored in the buffer when the WebSocket connection is interrupted, for example for example due to disconnection, those buffered events are discarded and are not broadcast when the client reconnects.

Only new events generated after the connection is re-established are sent to the client.

👥 Who this documentation is for ​

This section is primarily intended for:

  • developers and integrators working with real-time Catalyst updates
  • internal technical teams implementing event-driven UI behaviour
  • engineers who need to understand connection, buffering, and delivery characteristics

🧭 How to use this documentation ​

A good way to use this section is:

  1. start with the authentication flow for obtaining the WebSocket UUID
  2. review the endpoint-specific page for the resource you want to subscribe to
  3. check the documented batching and buffering behaviour before designing client-side handling
  4. validate reconnection behaviour in any production-facing implementation

⚠️ Notes ​

WARNING

This section documents technical and service-level WebSocket APIs. It should be used as implementation reference material and not treated as end-user documentation.

TIP

Use the sidebar to navigate directly to the resource-specific WebSocket pages in this section.