WebSocket subscription scope: conversationId vs. routing.queueId for OTel tracing

I’m setting up a Node.js service to capture Genesys Cloud conversation events via the Notification API WebSocket. The goal is to propagate OpenTelemetry trace context from the initial API call through to the event stream. I need to ensure that every event I receive is tagged with the correct trace ID.

The issue is figuring out the right subscription scope. I’ve been using routing.queueId because I want to monitor all interactions in a specific queue. However, when I look at the event payloads, the trace context doesn’t seem to stick across different conversation IDs within that same subscription.

Here’s the subscription payload I’m sending to wss://api-us.genesyscloud.com/v2/analytics/events:

{
 "type": "subscribe",
 "id": 1,
 "payload": {
 "scope": "routing.queueId",
 "queueId": "my-queue-id",
 "eventTypes": ["conversation.interaction.created", "conversation.interaction.updated"]
 }
}

The connection establishes fine. I get events. But when I try to inject the trace ID into the WebSocket handshake headers using the traceparent format, the events I receive don’t carry that context. I suspect the scope is too broad. If I switch to conversationId, I’d have to subscribe individually for every active conversation, which feels inefficient and might hit rate limits.

Is there a way to maintain trace context continuity when subscribing to a queue-level scope? Or am I missing a step in how the WebSocket handshake propagates the context? I’ve tried adding the traceparent header to the initial WebSocket request, but the backend events don’t reflect it.

Any ideas on how to structure this for distributed tracing?

Subscription to a queue ID aggregates events from multiple conversations. The trace context doesn’t survive that hop. You’ll want to subscribe to the specific conversation ID instead.

const sub = platformClient.NotificationsApi.subscribeToConversation(conversationId);

This keeps the trace context intact.