Examples of the Subscribe Call

Use these templates to build subscribe requests for common scenarios. These assume you have already established the WebSocket, sent the connection_init, and received the connection_ack.

Notes:

• Make id unique for the lifetime of the stream (until you send complete and the server closes).
• Include primaryKey in the selection set; it can be used to orchestrate a GET for the current resource state.
• Persist metadata.offset (string) and metadata.uniqueEventId for replay, idempotency, and logging.

Baseline: chainCode Only

A minimal subscription that receives full events.

{
  "id": "<id>",
  "type": "subscribe",
  "payload": {
    "variables": {
      "input": {
        "chainCode": "<Chain_Code>"
      }
    },
    "extensions": {},
    "operationName": null,
    "query": "subscription { newEvent(input: { chainCode: \"<Chain_Code>\" }) { metadata { offset uniqueEventId } moduleName eventName primaryKey detail { oldValue newValue elementName } } }"
  }
}

Delta Mode (delta: true)

Receive only changed attributes in detail to reduce payload size and increase throughput.

{
  "id": "<id>",
  "type": "subscribe",
  "payload": {
    "variables": {
      "input": {
        "chainCode": "<Chain_Code>"
      }
    },
    "extensions": {},
    "operationName": null,
    "query": "subscription { newEvent(input: { chainCode: \"<Chain_Code>\" delta: true }) { metadata { offset uniqueEventId } moduleName eventName primaryKey detail { oldValue newValue elementName } } }"
  }
}

Replay from Saved Offset

Resume from the last successfully processed offset after a disconnect.

{
  "id": "<id>",
  "type": "subscribe",
  "payload": {
    "variables": {
      "input": {
        "chainCode": "<Chain_Code>"
      }
    },
    "extensions": {},
    "operationName": null,
    "query": "subscription { newEvent(input: { chainCode: \"<Chain_Code>\" offset: \"<offset>\" }) { metadata { offset uniqueEventId } moduleName eventName primaryKey detail { oldValue newValue elementName } } }"
  }
}

Optional delta variant:

{
  "id": "<id>",
  "type": "subscribe",
  "payload": {
    "variables": {
      "input": {
        "chainCode": "<Chain_Code>"
      }
    },
    "extensions": {},
    "operationName": null,
    "query": "subscription { newEvent(input: { chainCode: \"<Chain_Code>\" offset: \"<offset>\" delta: true }) { metadata { offset uniqueEventId } moduleName eventName primaryKey detail { oldValue newValue elementName } } }"
  }
}

Latest Only (offsetType: "highest")

Skip history and receive just the current highest event, and then continue in real time. Use only if you do not need historical ordering.

{
  "id": "<id>",
  "type": "subscribe",
  "payload": {
    "variables": {
      "input": {
        "chainCode": "<Chain_Code>"
      }
    },
    "extensions": {},
    "operationName": null,
    "query": "subscription { newEvent(input: { chainCode: \"<Chain_Code>\" offsetType: \"highest\" }) { metadata { offset uniqueEventId } moduleName eventName primaryKey detail { oldValue newValue elementName } } }"
  }
}

Delta variant:

{
  "id": "<id>",
  "type": "subscribe",
  "payload": {
    "variables": {
      "input": {
        "chainCode": "<Chain_Code>"
      }
    },
    "extensions": {},
    "operationName": null,
    "query": "subscription { newEvent(input: { chainCode: \"<Chain_Code>\" offsetType: \"highest\" delta: true }) { metadata { offset uniqueEventId } moduleName eventName primaryKey detail { oldValue newValue elementName } } }"
  }
}

No Detail Array (orchestrate via REST)

Recommended if you plan to orchestrate using primaryKey to fetch the latest resource state via REST. Omits the detail array to reduce bandwidth.

{
  "id": "<id>",
  "type": "subscribe",
  "payload": {
    "variables": {
      "input": {
        "chainCode": "<Chain_Code>"
      }
    },
    "extensions": {},
    "operationName": null,
    "query": "subscription { newEvent(input: { chainCode: \"<Chain_Code>\" }) { metadata { offset uniqueEventId } moduleName eventName primaryKey } }"
  }
}

Filter by hotelCode

Adds a hotelCode filter in the input to target a specific property.

Note:

Some events do not include a hotelCode (especially profiles when profile sharing is enabled), so you may receive events with hotelId: null even when filtering.

{
  "id": "<id>",
  "type": "subscribe",
  "payload": {
    "variables": {
      "input": {
        "chainCode": "<Chain_Code>",
        "hotelCode": "<Hotel_Code>"
      }
    },
    "extensions": {},
    "operationName": null,
    "query": "subscription { newEvent(input: { chainCode: \"<Chain_Code>\" hotelCode: \"<Hotel_Code>\" }) { metadata { offset uniqueEventId } moduleName eventName primaryKey detail { oldValue newValue elementName } } }"
  }
}

Selecting Fields and Best Practices

• Keep the selection set narrow. Request only fields you will use; include metadata.offset, metadata.uniqueEventId, eventName, primaryKey, and any required detail elements.
• Consider delta: true to reduce bandwidth and CPU.
• Do not include the detail array if you plan to orchestrate via REST using primaryKey; be mindful of REST rate limits.
• Treat payloads as sensitive; avoid logging PII. Keep total headers under 8 KB.

ID Lifecycle

Use a single value for id per active stream and keep it constant throughout the subscription lifecycle.

• Generate a unique id after connection_init. Use the same id in the subscribe request.
• The server will tag all next messages for that stream with the same id; route handling by matching the id.
• When finishing, send complete with the same id, then wait for the server to close the stream. Do not reuse the id until the stream is fully closed.
• Reusing an id for multiple active operations or sending duplicate operation ids can result in errors (for example, 4409).