Auto-generating a client for outbound calls. The spec defines participant as OutboundParticipant, but the API rejects the payload with 400 Bad Request: “Malformed participant address”.
{
"to": "+15550199",
"from": "+15550100"
}
Is it possible to pass the address as a raw string instead of the nested object structure defined in the OpenAPI spec?
I think the spec requires to and from as nested objects not strings.
{
"to": { "phoneNumber": { "number": "+15550199" } },
"from": { "phoneNumber": { "number": "+15550100" } }
}This is typically caused by the strict schema validation on the to and from fields. The point above is correct, you must nest the phone number. Warning: ensure the number string includes the country code prefix +, or the API will reject it as an invalid address format.
This is a classic schema mismatch issue that trips up most people new to the outbound api. the suggestion above is correct, but you need to ensure the nested structure is exact. i often see this when people try to pass raw strings because the swagger spec for OutboundParticipant is strict. it requires the phoneNumber object to wrap the actual dial string. if you are using the purecloudplatformclientv2 sdk in node or python, you should construct the object programmatically rather than raw json to avoid typos. here is how i typically structure the request body for a simple call in my datadog integration scripts. the key is ensuring the number field is a string and includes the plus sign for e.164 format. if you omit the plus, the validation layer rejects it as a malformed address. also, make sure your oauth token has the outbound:campaign:execute scope. without it, you will get a 403 instead of a 400, which is a different can of worms.
{
"to": {
"phoneNumber": {
"number": "+15550199"
}
},
"from": {
"phoneNumber": {
"number": "+15550100"
}
}
}
if you are using curl for testing, remember to set the content-type to application/json. i usually wrap these calls in a retry loop because the outbound service can occasionally return 503s during peak load. once you fix the payload structure, the call should initiate correctly. you can then track the conversation id in datadog using a custom metric to monitor success rates. this approach saves a lot of debugging time later when tracing failed connections.
What’s happening here is that the OutboundParticipant schema strictly requires the nested object structure for phone numbers, so passing raw strings will always trigger a 400 error. You need to wrap the dial string in the phoneNumber.number property as shown above.
Warning: Ensure the number includes the + prefix, otherwise the API rejects it as an invalid address format.