Looking for advice on why our Digital Messaging API endpoints are returning HTTP 429 Too Many Requests errors specifically when triggered by inbound SIP events on our 15 BYOC trunks in the Asia/Singapore region. We manage a complex routing setup where inbound voice calls on these BYOC trunks trigger Architect flows that subsequently call the /api/v2/conversations/messaging endpoint to push notification payloads to our external CRM. This integration has been stable for six months, but since the last Genesys Cloud platform update, we are seeing a significant spike in throttling errors during peak business hours, which aligns with our highest call volume periods. The error responses include a Retry-After header of 5 seconds, but the volume of requests exceeds our ability to batch them effectively without introducing unacceptable latency into the customer journey. We have verified that our application logic adheres to the documented rate limits for the messaging API, yet the errors persist. The SIP registration status for all 15 trunks remains healthy with no 408 or 401 errors logged in the trunk activity reports, suggesting the issue is isolated to the API layer rather than the telephony infrastructure. We are using the Genesys Cloud SDK version 2.1 for our backend services, and the Architect flow logs show successful execution up to the point of the API call, after which the flow transitions to the error handling sub-flow. We have attempted to implement exponential backoff logic in our application code, but this has not resolved the underlying issue, as the 429 errors continue to occur at a rate of approximately 15% of all triggered requests. We are concerned that this throttling might be due to a misconfiguration in how the BYOC trunk events are being translated into API requests, or perhaps a regional limitation in the Asia/Singapore data center that we are unaware of. Any insights into whether there are specific best practices for handling high-volume API calls triggered by BYOC trunk events, or if there is a known issue with the messaging API rate limits in this region, would be greatly appreciated. We need to ensure that our customers receive timely notifications without experiencing delays caused by API throttling, and we are open to adjusting our architecture if necessary to accommodate the platform’s constraints.