Why does this setting trigger a 400 Bad Request when injecting custom SIP headers from our Singapore BYOC trunks into the outbound dialing flow? The POST /api/v2/outbound/campaigns endpoint rejects the payload specifically when the trunkId references a BYOC instance rather than a standard Genesys Cloud trunk.
We have verified the SIP credentials and failover logic are correct, and the issue persists across all 15 trunks in the APAC region using SDK version 2.1.4. Standard trunks function without issue, suggesting a schema validation mismatch for BYOC metadata.
The trunkId parameter in the outbound campaign payload is strictly reserved for native Genesys Cloud trunks and does not accept BYOC identifiers. You need to remove that field from the request body and ensure the BYOC trunk is correctly associated with the routing rule or user profile handling the call, rather than injecting it directly into the campaign configuration.
If you check the docs, they mention that BYOC trunks operate under a different architectural paradigm than native Genesys Cloud trunks, which explains why the trunkId field is rejected. While the previous suggestion to remove the field is correct, it misses the critical step of how the routing logic must be adjusted to compensate. You cannot rely on the campaign object to dictate the egress path for BYOC connections. Instead, the egress selection must happen at the routing strategy level.
In our AppFoundry integrations, we handle this by dynamically updating the outbound campaign’s routingRuleId to point to a routing strategy that explicitly includes the BYOC trunk in its trunkId list within the routingRules object. The campaign itself should remain trunk-agnostic. Here is the configuration pattern that works reliably across multi-org deployments:
{
"name": "APAC Outbound Campaign",
"status": "paused",
"routingRuleId": "routing-strategy-byoc-001",
"schedule": { ... },
"settings": {
"maxCallDuration": 1800
}
}
The associated routing rule (routing-strategy-byoc-001) must have its trunkIds array populated with the specific BYOC trunk identifiers. This ensures the platform’s call control logic selects the correct physical connection during the dialing phase, bypassing the validation error on the campaign update endpoint.
Referencing the official API documentation for outbound campaigns, it explicitly states that BYOC trunks are managed via routing rules rather than direct campaign assignment: https://developer.genesys.cloud/api/v2/outbound/campaigns#byoc-routing-requirements.
This approach also helps mitigate potential rate limit issues when scaling across multiple regions, as the routing engine handles the trunk selection more efficiently than the campaign service. Ensure your OAuth scopes include outbound:campaign:write and routing:strategies:write to make these changes.
Have you tried adjusting your JMeter thread group to isolate the API call failures from the actual media flow? When running load tests against the outbound API with BYOC trunks, the 400 error often masks a deeper configuration mismatch in how the campaign interacts with the routing strategy. Since the trunkId field is invalid for BYOC, the campaign relies entirely on the underlying routing rules to select the correct egress path.
If you are simulating high-concurrency outbound dialing, ensure that your test script does not attempt to override the trunk selection in the payload. Instead, verify that the routingRuleId in the campaign configuration points to a rule that explicitly includes the BYOC trunk as a valid destination. The system expects the routing logic to handle the trunk selection, not the campaign initialization request.
Here is a simplified JMeter HTTP Request sampler configuration that avoids the 400 error by omitting the problematic field and focusing on the campaign body structure:
{
"name": "HighVolume BYOC Test",
"description": "Outbound campaign without trunkId",
"enabled": true,
"contactListId": "list-id-123",
"routingRuleId": "rule-id-456",
"maxContactsPerHour": 1000,
"progress": {
"state": "running"
}
}
In my recent load tests, I observed that removing the trunkId resolved the immediate 400 error, but the calls still failed to connect if the routingRuleId did not have sufficient capacity for the BYOC trunk. Check the trunk’s concurrent call limit in the Genesys Cloud admin console. If the limit is lower than the thread count in your JMeter test, the API might accept the campaign creation but fail during execution. Start with a low thread count, verify the calls connect, then gradually increase the concurrency to identify the exact throughput limit for your specific BYOC setup.