Is it possible to retrieve historical BYOC trunk registration states via the PureCloud API for audit compliance?

Is it possible to retrieve historical BYOC trunk registration states via the PureCloud API for audit compliance? We are currently managing 15 BYOC trunks across APAC regions, and our internal security team requires a comprehensive log of all registration changes, including successful registrations, failures, and credential updates, for the past 12 months. The standard GET /api/v2/telephony/providers/edge/trunk/{trunkId} endpoint only provides the current configuration and status snapshot. While the /api/v2/analytics/events queries allow us to pull some high-level event data, the granularity regarding specific SIP registration outcomes (e.g., 403 Forbidden vs 401 Unauthorized) seems insufficient for our detailed carrier failover analysis. We need to correlate specific registration drops with carrier-side maintenance windows, but the existing analytics endpoints do not seem to expose the detailed SIP response codes or the exact timestamp of the registration failure in a format that can be easily exported for long-term storage.

We have attempted to use the /api/v2/telephony/providers/edge/trunk/{trunkId}/registration endpoint to check real-time status, but this is clearly intended for operational checks rather than historical reporting. Furthermore, the Event Analytics API appears to have a retention policy that limits us to recent data, which is problematic for our quarterly compliance reviews. Given our setup involves complex failover logic where trunks switch between primary and secondary carriers, missing registration events could indicate a silent failure in our routing architecture. Are there any undocumented endpoints or alternative methods, such as leveraging the Data Action framework to push these specific registration events to an external data warehouse in real-time, that could solve this historical data gap? We are open to setting up a custom Lambda function if the native API does not support this level of historical detail, but we want to avoid reinventing the wheel if a native solution exists.

The docs actually state that historical trunk state is not exposed through the standard Telephony Providers API. The GET endpoint only returns the live snapshot. For audit trails, the system relies on the Activity Log API. You can query this using the search parameters to filter by resource type “telephony_edge_trunk”. This captures registration events, status changes, and credential updates as discrete audit records.

A simple JMeter GET request to /api/v2/analytics/activity-logs/query with a JSON body specifying the date range and resource ID can pull this data. Be aware that the API returns paginated results. Under high concurrency, if you are pulling logs for many trunks simultaneously, you might hit the 429 rate limit. It is safer to serialize the requests or implement a backoff strategy in your load test script to avoid throttling. This approach provides the granular history needed for compliance without relying on unsupported endpoints.

Note: Ensure your admin account has the activity-log:view permission before running these queries.

Pretty sure the Activity Log API is indeed the way to go, but make sure you filter by resourceType “telephony_edge_trunk” and include the eventType for registration changes. This ensures you capture every state transition for those APAC trunks, which is exactly what the security team needs for their twelve-month audit window.