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.
• Streaming does not support requesting specific Business Data Elements in the subscribe request. You either request `detail` or you do not request it; element-level inclusion is determined by the BE template, and `delta=true` removes unchanged elements.

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 GUID value for id per active subscription and keep it constant throughout the subscription lifecycle.

Generate a GUID for id after connection_init. Use the same id in the subscribe request, match it on server next messages, and send it again in the complete request.

Oracle recommends using a GUID because it avoids collisions and makes troubleshooting faster. If you contact Oracle Support, provide the GUID used for the subscription, the application key, chain code, approximate timestamp, and any offset or close code observed.

• 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).