Screen Recording API 400 Bad Request on BYOC Trunk Metadata

I can’t seem to figure out why the Screen Recording API is returning a 400 Bad Request when attempting to filter recordings by specific BYOC trunk identifiers. We are managing 15 BYOC trunks across the APAC region, specifically targeting the Singapore and Jakarta endpoints. The environment is running Genesys Cloud version 2023-11 with the latest Architect updates applied. When querying the /api/v2/recordings endpoint with a custom filter for trunk_id matching our primary SIP trunk credentials, the response payload explicitly states that the filter criteria are invalid. This is puzzling because the same trunk_id values work perfectly in the standard Reporting dashboard for call detail records. We have verified the SIP registration status on all SBCs, and they are stable with no TLS handshake failures or 408 timeouts. The issue seems isolated to the recording retrieval logic rather than the underlying trunk connectivity. We are using the REST API directly from a Python script running in our local AWS instance, ensuring no proxy interference. The error persists even when simplifying the query to request only the most recent 10 recordings, suggesting a fundamental mismatch in how the recording service indexes trunk metadata compared to the CDR service.

The specific error message returned is {"code": "bad_request", "message": "Filter criteria contains unsupported field: trunk_id"}. This contradicts the public documentation which lists trunk_id as a valid filterable attribute for recording searches. We have attempted to use the outbound_route ID instead, but this does not provide the granularity needed for our compliance reporting on carrier-specific call quality. Is there a known limitation with BYOC trunk metadata indexing in the recording service? We are observing this behavior consistently across all 15 trunks, not just a single endpoint. The timestamp on the recordings aligns perfectly with the CDR data, so the recordings are being created successfully. The problem is strictly in the retrieval and filtering stage. We need to extract recordings for specific carrier failover events, and without the ability to filter by trunk, we are forced to download the entire recording pool and process it locally, which is inefficient and risks missing data due to retention policies. Any insights into whether this is a documentation error or a backend indexing delay would be appreciated.

The documentation actually says…

The /api/v2/recordings endpoint does not support filtering by trunk_id directly in the query parameters. This is a common limitation when trying to correlate media metadata with telephony infrastructure data. The API schema for recordings only accepts filters for interaction_id, media_type, and date_range. Attempting to pass a custom trunk identifier results in a 400 Bad Request because the server rejects the unrecognized parameter immediately.

To achieve this, you must first retrieve the interactions associated with your BYOC trunks via the /api/v2/telephony/phone-connections or /api/v2/interactions endpoints, which do support trunk-based filtering. Once you have the list of interaction_id values, pass them as a comma-separated list to the recordings endpoint.

Example logic:

1. GET /api/v2/interactions?filter=telephony_trunk_id:YOUR_TRUNK_ID
2. Extract id from response.
3. GET /api/v2/recordings?filter=interaction_id:ID1,ID2,ID3

This two-step approach aligns with the API design patterns for media retrieval.

The root of the issue is that the /api/v2/recordings endpoint strictly validates query parameters against a predefined schema. As mentioned above, trunk_id isn’t a valid filter key, which triggers the 400 Bad Request immediately. From a load testing perspective, this is actually a good thing. If you were running a JMeter script with high concurrency (say, 50 threads per second) and the server accepted an invalid parameter, it might process it inefficiently or return partial data, skewing your throughput metrics.

Instead of filtering at the API level, pull the recordings within your date_range and filter client-side. Be careful with pagination though. If you’re dealing with high call volumes, iterating through all pages in a loop can hit rate limits quickly. A safer approach is to use the interaction_id to fetch specific recordings if you already have that data from the BYOC logs. This avoids unnecessary API calls and keeps your test results clean.