Agent scripting api returning 400 on trunk assignment

General Discussion
1

just noticed that the /v2/apiplatform/knowledge/script endpoint returns a 400 bad request when assigning byoc trunk id 778912 to a new script. the payload validates fine in postman but fails via python requests 2.28.1. anyone seen this with sip trunk bindings in architect?

2

Ah, yeah, this is a known issue… When running JMeter simulations against the /v2/apiplatform/knowledge/script endpoint, we often see 400 errors if the trunk assignment payload lacks specific metadata required by the GC validation engine. The Python requests library might not be sending the exact JSON structure expected when binding a BYOC trunk.

The documentation suggests that the trunk object needs more than just the ID. It requires a valid type and often a siteId if the trunk is site-bound. Missing these fields causes the backend to reject the request before it even hits the routing logic.

Try adjusting your payload structure as follows:

  1. Ensure the trunk field is an object, not a string.
  2. Include the type field set to BYOC.
  3. Add the siteId if your trunk is associated with a specific site.

Example JSON payload:

{
 "name": "Test Script",
 "flow": {
 "type": "conversation",
 "actions": [
 {
 "id": "transfer",
 "type": "transfer",
 "queueId": "12345",
 "trunk": {
 "id": "778912",
 "type": "BYOC",
 "siteId": "your-site-id-here" 
 }
 }
 ]
 }
}

In our recent load tests with JMeter 5.4, we noticed that omitting the type field caused immediate 400s. The API is strict about schema validation during high-concurrency scenarios. Double-check that your Python script is serializing the dictionary correctly into JSON. Also, verify that the trunk ID 778912 is actually active and not in a DEPROVISIONED state. If the trunk is down, the script creation will fail regardless of the payload structure. This usually resolves the issue.

3

{
“trunk”: {
“id”: “778912”,
“type”: “byoc”
}
}

You need to explicitly define the `type` field as `byoc` within the trunk object. The validation engine rejects payloads containing only the ID, as this is a standard requirement for external trunk bindings in the knowledge API.