Trying to propagate OTel trace context when initiating an outbound call on behalf of an agent via POST /api/v2/conversations/calls. The call works, but the trace ID injected in the custom_attributes isn’t showing up in downstream spans. Here’s the payload snippet:
{
"from": { "id": "agent_id" },
"to": [{ "id": "customer_id" }],
"custom_attributes": { "trace_id": "abc123" }
}
Getting a 400 if I try to put it in routing_data. Is there a specific field for trace injection here?
You’re hitting a 400 because the API expects specific structure for custom attributes, but more importantly, trace context doesn’t live there. Custom attributes are for business logic, not observability. The platform ignores them for tracing.
If you want real distributed tracing, you need to use the trace_context object in the request header or body, depending on the SDK version. For raw API calls, you inject it via headers. For outbound calls specifically, the payload needs to support the trace injection pattern.
Here’s the corrected payload structure. You don’t put the trace ID in custom_attributes. You use the trace_context block if supported by your integration point, or rely on the platform’s automatic injection if the initiating request has the proper headers.
{
"from": {
"id": "agent_id"
},
"to": [
{
"id": "customer_id"
}
],
"trace_context": {
"trace_id": "abc123",
"span_id": "def456"
}
}
Wait, actually, for POST /api/v2/conversations/calls, the trace_context isn’t always valid in the body for all versions. The reliable way is to ensure the HTTP request itself carries the W3C Trace Context headers. The platform picks those up and attaches them to the conversation lifecycle.
So, instead of fiddling with the JSON body, check your HTTP client. Add these headers to your POST request:
Traceparent: 00-abc123-def456-01
Tracestate: vendor=value
The 400 you saw was likely because trace_id isn’t a valid key for custom_attributes in that specific context, or the schema validation failed on an unexpected field. The platform validates custom attributes strictly. If you need to pass data for your own app logic, use a different key, but don’t expect it to feed the OTel pipeline. The pipeline reads from the conversation metadata, which is populated by the headers, not the body attributes.
Check your API logs. The 400 response body usually tells you exactly which field failed validation. It’s probably complaining about the structure of custom_attributes.