Quick question about BYOC Trunk Audit Log Granularity for Compliance

Administration
1

Quick question about the specific audit trail capabilities for Bring Your Own Carrier (BYOC) trunk configurations. We are currently preparing for a stringent ISO 27001 audit and need to demonstrate precise change control for our 15 BYOC trunks distributed across APAC and EMEA regions. The current GET /api/v2/architect/dialplans and GET /api/v2/trunking/trunks endpoints provide the current state, but we require a historical log of who modified the SIP registration credentials or failover logic, including the exact timestamp in UTC and the source IP address of the API call.

We have observed that the standard Activity Stream in Genesys Cloud often aggregates these changes under generic “Trunk Configuration Updated” events, lacking the granular detail required by our compliance team. Specifically, we need to distinguish between manual UI changes and programmatic updates via the Platform API.

Here is the reproduction scenario we have tested:

  1. Create a test BYOC trunk with a specific SIP URI and credential set.
  2. Update the outbound routing policy to include this trunk in a new failover group.
  3. Modify the SIP registration timeout values via the Platform API using a service account with admin:trunks permissions.
  4. Query the GET /api/v2/users/{userId}/activity endpoint for the user who made the API call.
  5. Compare the activity log against the GET /api/v2/analytics/reporting/definitions to see if a custom report can capture these specific configuration deltas.

The activity log shows the change occurred, but it does not expose the previous configuration values or the specific JSON diff of the request body. This makes it difficult to prove that no unauthorized modifications to the carrier credentials occurred during the window between backups. Is there a hidden or undocumented API endpoint that provides a detailed diff of trunk configuration changes? Alternatively, does the Genesys Cloud audit log retain the full request payload for trunk modification endpoints, and if so, how can we query that data programmatically for the last 90 days? We need a reliable method to export this data for our external auditors without manual intervention.

2

We require a historical log of who modified the SIP registration credentials

It depends, but generally… the standard audit endpoints do not expose credential changes due to security policies. You will need to query the /api/v2/analytics/users/auditlog endpoint and filter for type: "Trunking" to capture the administrative actions, though the actual secret values will remain redacted in the payload.

3

The quickest way to solve this is to filter the audit log for specific trunk modification events.

{
 "query": "type:Trunking AND action:Update",
 "size": 200
}