I’m curious as to why the /api/v2/trunks/byoc endpoint throws a 500 Internal Server Error when filtering for trunks with a status of ‘INACTIVE’?
We have 15 BYOC trunks across APAC. Pulling active trunks works fine, but including the inactive ones crashes the export job. This breaks our automated compliance reporting pipeline.
Ah, yeah, this is a known issue when the payload size spikes during bulk retrieval. The 500 error usually stems from the backend struggling to serialize inactive trunk states alongside active ones in a single request.
Try breaking down the fetch logic:
- Filter by
status=ACTIVE first to get the base dataset.
- Make a separate call for
status=INACTIVE with a smaller page size (e.g., pageSize=10).
- Merge the results locally in your script.
This avoids hitting the internal serialization timeout. Also, check if your API client is retrying immediately on 500. Genesys Cloud might be throttling the endpoint temporarily. Adding a 5-second backoff before retrying the inactive trunk fetch usually stabilizes the pipeline. If the error persists, verify that the inactive trunks don’t have corrupted metadata in the BYOC configuration, as that can cause unexpected serialization failures during export jobs.