Architect Script API failing with 422 on BYOC trunk context

Could use a hand troubleshooting this persistent 422 error when updating script configurations via the Architect API for agents routed through our AP-SG BYOC trunks. The payload validates locally, but the endpoint rejects the update with a schema mismatch on the media_type field.

The media_type property must match the trunk’s configured voice capability.

Has anyone seen this conflict when mixing SIP trunks with specific DTMF relay settings?

Ah, yeah, this is a known issue! The WFM integration often conflicts with BYOC media settings if the trunk isn’t explicitly marked as voice-capable in the provisioning dashboard. Check out this guide on aligning trunk capabilities: https://support.example.com/wfm-byoc-media-fix.

My usual workaround is to verifying the exact media profile assigned to the BYOC trunk in the Admin console, as the Architect API is strict about matching the media_type in the script payload with the trunk’s declared capabilities. The 422 error often occurs when the trunk is provisioned for G.711 only, but the script configuration attempts to reference a codec or DTMF relay mode (like RFC 2833) that isn’t explicitly enabled on that specific trunk context.

For legal discovery workflows, we often have to ensure that the recording metadata captures the correct channel type. If the media type mismatches, the recording might fail to tag correctly, which breaks the chain of custody for export jobs.

Check the trunk configuration in Admin > Telephony > BYOC. Ensure the “Voice” capability is checked and that the DTMF settings match what the script expects. If you are using a specific codec, make sure it is listed in the trunk’s allowed codecs.

Here is a sample JSON payload structure that should align with a standard G.711 SIP trunk:

{
 "id": "script-id-123",
 "media_type": "voice",
 "outbound_settings": {
 "dtmf_type": "rfc2833",
 "codec": "pcmu"
 }
}

If the trunk supports multiple codecs, the script must explicitly define which one to use for outbound calls. Also, verify that the user making the API call has the architect:script:update permission and is not restricted by any role-based access control (RBAC) policies that might limit changes to BYOC resources.

Double-checking these settings usually resolves the schema mismatch. If the issue persists, review the API logs for the specific validation error code, as it might point to a deprecated field in the payload.