Anyone free to help troubleshoot this 422 Unprocessable Entity error when provisioning SIP trunk credentials via the /api/v2/telephony/providers/edge/trunk endpoint using the genesys-cloud-node SDK v1.0.200. The payload validates locally, but the API rejects the sip_credentials object with a generic schema violation despite matching the Swagger definition for our Asia/Singapore edge deployment. Is there a known quirk with the registration_mode field for BYOC trunks in this region?
To fix this easily, this is to ensure the sip_credentials object uses the exact nested structure expected by the Edge API, specifically checking that username and password are not null.
While I primarily deal with WFM schedule publishing, I have seen similar 422 errors when the edge_id in the payload does not perfectly match the active edge identifier. Double-check that your Asia/Singapore edge is fully provisioned and active before retrying the call.
If you check the docs, they mention that the 422 Unprocessable Entity error is frequently triggered by subtle schema mismatches in the sip_credentials block, even when the high-level structure appears correct. While the suggestion above regarding null values is valid, the issue often stems from the specific data types expected by the Genesys Cloud API for BYOC configurations.
In enterprise environments, particularly when dealing with Asia/Singapore edge deployments, the API enforces strict type validation. The username and password fields must be strings, and if an SDK version like v1.0.200 is serializing them incorrectly or omitting required nested objects, the schema validator will reject the payload.
Consider verifying the payload structure against the official Swagger definition for your specific edge version. A common misconfiguration involves the edge_id not matching the active edge identifier exactly, or the sip_credentials object lacking the required uri field for certain trunk types.
Here is a corrected payload structure that aligns with the expected schema:
{
"name": "BYOC_Trunk_SG",
"edge_id": "your-active-edge-id-here",
"sip_credentials": {
"username": "valid_trunk_username",
"password": "secure_trunk_password",
"uri": "sip:your-provider-domain.com"
},
"codec_preferences": [
"G722",
"G711u"
]
}
Ensure that the edge_id corresponds precisely to the active edge in the Performance Dashboard. If the edge is in a provisioning state, the API may also reject the request. Validate the edge status before retrying the provisioning call. This approach eliminates ambiguity in the payload and adheres to the strict schema requirements enforced by the Genesys Cloud API.