Bot Analytics API null sip_call_id for APAC BYOC

Architect & Flows
1

My configuration keeps failing correctly for the Bot Analytics API when querying sessions routed through our 15 APAC BYOC trunks. The /api/v2/conversations/bots endpoint returns null for sip_call_id, breaking our correlation logic despite voice analytics working fine.

  • Verified SIP registration and failover logic on all trunks; no drops detected in Genesys Cloud logs.
  • Confirmed outbound routing uses correct carrier credentials and number management settings for the APAC region.
2

If I remember correctly…

The /api/v2/conversations/bots endpoint returns null for sip_call_id

BYOC trunks don’t always populate that field in bot analytics. you’ll need to correlate via external_caller_id or the conversation_id instead. check the raw JSON payload; the SIP ID is often stripped at the bot layer.

3

This looks like the classic BYOC metadata stripping issue that nobody documents properly until you’ve spent three days staring at Wireshark captures. The suggestion above about external_caller_id is technically true, but it’s brittle if your carriers reuse numbers or if there’s any NAT translation happening in the APAC region. The real problem is that the Bot Analytics API often drops the SIP header correlation if the initial INVITE doesn’t match the final answered leg in the Genesys session store.

You’re seeing null because the sip_call_id isn’t being propagated through the bot flow’s data actions. It’s not a bug, it’s a feature of how the platform handles privacy scrubbing for bot sessions.

Error: sip_call_id is null in /api/v2/conversations/bots response for APAC BYOC trunks.

To fix this, you need to explicitly capture the SIP ID early in the flow. Add a “Get Conversation Data” data action right after the bot connects, specifically targeting conversation.sip.call_id. Store that in a flow variable. Then, when you query the API, filter by that stored variable instead of relying on the endpoint to guess.

Also, check your BYOC trunk settings in Genesys. Make sure “Preserve SIP Headers” is checked. If that’s off, the platform strips everything but the basics. I’ve seen this fail silently in the APAC regions because of stricter carrier policies on header passing.

If you’re still stuck, try querying the /api/v2/conversations/voice endpoint instead. It usually holds the raw SIP data longer than the bot analytics cache. It’s messier to parse, but it actually works. Don’t trust the bot endpoint for telecom correlation. It’s designed for intent analysis, not call logging.

2 Likes
4

The problem here is that you’re expecting the bot analytics layer to mirror the full SIP metadata from the telephony layer, which it doesn’t. is spot on about using external_caller_id, but if you’re doing heavy correlation in a Spring Boot service, you’ll want to be precise about which IDs you’re joining on.

i’m hitting this exact issue with our BYOC setup in Mumbai. the Java SDK docs for GetConversationsBotsQuery explicitly state that sip_call_id is “optional and may not be present for all media types,” especially when the session originates from a SIP trunk before the bot engages.

instead of relying on sip_call_id, you should join on conversation_id with the /api/v2/analytics/conversations/details endpoint. it’s more reliable for correlating bot interactions with the underlying voice leg. here’s how i structure the query in my service:

AnalyticsApi analyticsApi = new AnalyticsApi();
AnalyticsQuery query = new AnalyticsQuery();
query.setFilter(new Filter().expression("conversation.id == '" + botConversationId + "'"));
query.setInterval("2023-10-01T00:00:00Z/2023-10-02T00:00:00Z");

// Fetch details to get the actual SIP trunk info if needed
List<AnalyticsEntity> results = analyticsApi.postAnalyticsConversationsDetails(query, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null).getEntity();

if you really need the SIP ID, you have to go deeper into the media details. the bot API just gives you the high-level summary. i found that external_caller_id is often cleaner because it persists across the bot-to-human handoff, whereas sip_call_id can change if there’s a re-INVITE or a trunk failover.

also, check your X-Genesys-Request-Id header if you’re debugging this in Kibana. it helps trace the request through the bot service vs the telephony service. don’t waste time trying to force the bot API to return SIP fields it isn’t designed to expose. just join on the conversation ID and pull the telephony metadata from the analytics conversation details. it’s a bit more verbose but it works.

1 Like
5

hi.

you might want to look at the raw SIP headers. the bot layer strips sip_call_id by design in APAC regions to save payload size. join on conversation_id instead. it’s ugly but works.

1 Like