How should I properly to implement a robust polling mechanism within a Genesys Cloud Data Action to verify the operational status of BYOC trunks before initiating high-volume outbound campaigns in the AP-Southeast-1 region. We are managing fifteen BYOC trunks across multiple carriers and need to ensure that our Architect flows do not route calls to trunks that are currently experiencing SIP registration failures or carrier-side blackouts. The current implementation uses a custom Data Action that queries the /api/v2/trunks endpoint to retrieve the trunk configuration and status. However, we are observing a race condition where the Data Action returns a ‘connected’ status based on cached metadata, but the actual SIP registration has failed due to carrier-specific quirks or network jitter spikes common in our region. This results in a high volume of SIP 408 Request Timeout errors and subsequent call failures, which negatively impacts our analytics reporting and agent performance metrics. The Data Action is configured to run synchronously within the Architect flow, and we are using the standard Genesys Cloud Python SDK version 2.10 for the backend logic. We have attempted to introduce a retry loop with exponential backoff within the Data Action, but this significantly increases the latency of the call setup process, leading to poor user experience and increased abandonment rates. Additionally, the analytics dashboard shows discrepancies between the reported trunk uptime and the actual successful call completion rates, suggesting that the status polling is not accurately reflecting the real-time health of the SIP connections. We need a more reliable method to check the active SIP registration status and carrier failover logic before routing calls. Is there a specific API endpoint or Data Action pattern that provides real-time trunk health checks rather than relying on the static configuration status. We are also considering implementing a webhook-based solution to update trunk status in real-time, but we are concerned about the complexity and potential security implications of exposing our internal systems to external carrier notifications. Any advice on best practices for handling BYOC trunk status verification in Data Actions would be appreciated, especially given the specific challenges of managing multiple carriers in the AP-Southeast-1 region with varying reliability and failover behaviors.