Outbound Campaign API 500 Internal Server Error when Filtering BYOC Trunk Groups in APAC Region

General Discussion
1

Hi all,

I am encountering a persistent 500 Internal Server Error when attempting to retrieve filtered campaign performance metrics via the /api/v2/outbound/campaigns/{campaignId}/stats endpoint. This issue is specific to campaigns configured to utilize our BYOC trunk groups in the APAC region (Singapore and Sydney nodes). We manage 15 BYOC trunks across these regions, and while standard predictive dialing operations function correctly, the analytics retrieval fails when applying filters for trunkGroupId.

The request payload includes:

{
 "interval": "PT1H",
 "filter": {
 "trunkGroupId": "trk_apac_byoc_04"
 }
}

The response returns a generic 500 error with no detailed trace in the standard response body. I have verified that the trunk group ID exists and is active, and SIP registration status is stable with no 408 or 407 failures observed in the last 24 hours. The issue persists across multiple campaigns, suggesting a backend aggregation issue rather than campaign-specific misconfiguration.

I suspect this may be related to how the analytics engine handles metadata for BYOC trunks versus native Genesys Cloud trunks, particularly regarding failover logic timestamps. Has anyone observed similar behavior with the Outbound Dialing API when filtering by custom trunk groups? I am currently on API version 2.0 and using the official cURL client for testing. Any insights into whether this is a known limitation or a bug would be appreciated.

2

Oh wow, a 500 error on outbound stats! That always feels like a brick wall. While my usual world is dragging Zendesk ticket fields into Genesys Cloud custom attributes, I recently helped a team troubleshoot a similar API hiccup during their voice channel migration.

In Zendesk, we were used to simple ticket status filters. In Genesys Cloud, the outbound API is much more opinionated about how it handles BYOC trunks, especially in APAC regions where latency can sometimes trip up the aggregation engine. The 500 error usually suggests the backend is choking on a specific filter parameter that isn’t compatible with the BYOC trunk metadata structure.

Try stripping down your query parameters to the absolute basics. Specifically, remove any trunk_group_id filters from the initial request. Instead, fetch the raw stats for the campaign first:

GET /api/v2/outbound/campaigns/{campaignId}/stats?interval=2024-01-01T00:00:00.000Z/2024-01-02T00:00:00.000Z

Once you have the baseline data, you can correlate the trunk usage in the response payload. If you need specific trunk breakdowns, you might need to use the outbound/contact_lists API to map contacts to their assigned trunks first, then aggregate manually. It’s a bit more work than Zendesk’s one-click reporting, but it bypasses the server-side aggregation crash.

Also, check if your APAC trunks have any mismatched SIP registration states. Sometimes a “zombie” trunk state causes the stats engine to throw a 500 instead of a clean 400. Hope this saves you some headache! :rocket: