Skip to content

Object Record Events ​

This page documents the WebSocket endpoint used to receive real-time Object Record change events in Catalyst.

The endpoint broadcasts Object Record-related events so that connected clients can reflect changes without polling or refreshing the page. It is intended for real-time UI updates and event-driven integrations that need to track record creation, value changes, ownership changes, assignment changes, document generation, and deletion.

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.

Endpoint overview ​

This page covers the following endpoint:

  • GET /ws/events/object-records/

GET /ws/events/object-records/ ​

Subscribes the client to a stream of Object Record change events.

The endpoint broadcasts updates for up to 1,000 Object Records every 5 seconds.

Permissions ​

Requires authentication.

Authentication is based on the uuid query string parameter used when establishing the WebSocket connection.

Request ​

Upgrade request example ​

text
Request Method: GET
Connection: Upgrade
Upgrade: websocket

Query parameters ​

Optional filters can be passed in the WebSocket connection query string, alongside the uuid authentication parameter.

ParameterTypeNotes
object_class_idscomma-separated int listOptional. Limits delivered notifications to events where object_class_id matches one of the provided IDs.
field_idscomma-separated int listOptional. Limits delivered object_record_value_changed notifications to events that include at least one matching Object Class Field ID. Other event types are not restricted by this parameter.

Examples:

text
GET /ws/events/object-records/?uuid=<uuid>&object_class_ids=1,2
GET /ws/events/object-records/?uuid=<uuid>&field_ids=10,11
GET /ws/events/object-records/?uuid=<uuid>&object_class_ids=1,2&field_ids=10,11

Empty parameters are treated as no filter. Invalid comma-separated values are silently ignored. A filter is active only when at least one valid integer value remains after parsing.

Filtering behaviour ​

When object_class_ids is provided, the server delivers only notifications where object_class_id matches one of the provided values. Notifications for other Object Classes are dropped server-side.

When field_ids is provided, it applies only to object_record_value_changed notifications:

  • a value-changed notification is delivered only when at least one changed field ID matches the provided field_ids
  • the forwarded field_ids list contains only the matched subset
  • other event types, such as object_record_created and object_record_deleted, are not restricted by this filter

When both object_class_ids and field_ids are provided, both filters apply. A notification must pass the Object Class filter and, for object_record_value_changed notifications, the field filter to be delivered.

Connections without object_class_ids or field_ids receive all events, preserving the previous behaviour.

Response ​

After the connection is established, the server sends a list of Object Record change events.

Each list item contains the following fields:

KeyTypeNotes
object_record_idintObject Record identifier
object_class_idintRelated Object Class identifier
eventstringObject Record event type
field_idsarray[int]Included on object_record_value_changed events. Contains the changed Object Class Field IDs. When field_ids filtering is active, contains only the matched subset.
timestampdatetimeTime the event was created

For object_record_value_changed, a single backend event with multiple changed fields produces one WebSocket message with a field_ids list. The message does not use a single field_id integer.

Available events ​

The following event values are supported:

  • object_record_created
  • object_record_value_changed
  • object_record_owner_initialized
  • object_record_owner_added
  • object_record_owner_removed
  • object_record_assignee_added
  • object_record_assignee_removed
  • object_record_deleted
  • object_record_document_generated

Success ​

  • WebSocket upgrade status: 101 Switching Protocols

Example payload ​

json
[
  {
    "object_record_id": 1,
    "object_class_id": 1,
    "event": "object_record_owner_initialized",
    "timestamp": "2025-01-16T11:07:57.954470+00:00"
  },
  {
    "object_record_id": 1,
    "object_class_id": 1,
    "event": "object_record_created",
    "timestamp": "2025-01-16T11:07:57.934931+00:00"
  },
  {
    "object_record_id": 1,
    "object_class_id": 1,
    "event": "object_record_value_changed",
    "field_ids": [10, 11],
    "timestamp": "2025-01-16T11:08:07.444085+00:00"
  }
]

Ordering and delivery ​

Sorting cannot be controlled by the client.

By default, events are delivered in creation order. Where results are chunked, events are ordered in ascending order by event timestamp.

Errors ​

ErrorResponse code / close statusMessage
Incorrect WebSocket URL pathClose: 1000 Normal Closure"type": "error", "error_code": "ERR_INCORRECT_URL", "detail":"Incorrect WebSocket URL."
Invalid UUIDClose: 1000 Normal Closure"type": "error", "error_code": "ERR_INVALID_UUID", "detail":"A valid UUID is required."
Sending messages to this WebSocket is not supportedClose: 1000 Normal Closure"type": "error", "error_code": "RECEIVE_NOT_SUPPORTED", "detail": "This WebSocket connection does not support receiving messages."
Rate limit exceededClose: 1000 Normal Closure"type": "error", "error_code": "ERR_RATE_LIMIT_EXCEEDED", "detail":"The rate limit for requests has been exceeded. Please wait before trying again."
Error during the handshake500 Internal Server Error

Notes ​

WebSocket standard close/error definitions are described in RFC 6455.