Quick question about the Quality Management API behavior when updating form versions in a multi-region BYOC environment.
We are managing fifteen BYOC trunks across APAC and EMEA regions. The setup involves strict SIP registration failover logic to ensure carrier redundancy. Recently, we attempted to automate quality form updates via the /api/v2/quality/forms endpoint using the SDK v1.24.0.
The payload includes a specific version increment and updated scoring criteria. The request fails immediately with a 422 Unprocessable Entity error. The error message cites a ‘version_conflict’ but does not specify which concurrent modification triggered it.
This is puzzling because our automation script runs during a maintenance window. No other users have access to the Quality module during this time. The SIP trunk status is stable, and outbound routing is functioning correctly. We verified that no other API calls were made to the quality module in the preceding five minutes.
The issue appears isolated to forms associated with specific carrier groups. Forms linked to the primary SIP trunk update without issue. However, forms tied to the secondary failover trunks consistently return the 422 error.
We have checked the audit logs. No manual edits are recorded. The API response headers show a standard retry-after value of zero, indicating no rate limiting. The conflict seems logical rather than throttling-related.
Is there a known coupling between trunk configuration state and quality form versioning? We suspect that the system might be locking forms based on associated interaction metadata from the BYOC trunks. This would explain why only secondary trunk forms are affected. The primary trunk interactions are processed differently in the WFM analytics pipeline.
Any insights into this dependency would be appreciated. We need to resolve this to maintain our automated quality assurance workflows. The current manual override process is unsustainable for our scale.