400 Bad Request on POST /api/v2/quality/evaluations returning interaction_unavailable for a digital chat session. The interaction ID resolves fine via the Interactions API, yet the Quality endpoint throws a validation error claiming the resource doesn’t exist.
Requests to the Seoul region endpoint fail. The chat interaction closed successfully three minutes ago, status is closed, but the bulk evaluation job keeps failing on this specific interaction type. Payload structure matches the voice evals that work fine.
{
"errorCode": "interaction_unavailable",
"message": "The interaction with id 'chat-99281-xk2' is not available for evaluation.",
"status": 400
}
Evaluation form version verification passed. It supports digital media types. The form ID checks out. Could be a metadata propagation lag. Documentation mentions a sync delay for voice, but nothing about messaging channels.
Logs show the request hits the load balancer but drops at the validation layer. No 403, just a hard 400.
The interaction payload from the GET request shows wrapup_code is present. Agent finished the chat.
[2023-10-24T14:32:11.450Z] ERROR: QualityClient.createEvaluation - 400 interaction_unavailable
Retry logic after 5 seconds returns the identical error.
The interaction_unavailable error points to a sync gap between the real-time GET /api/v2/interactions endpoint and the Quality evaluation store. The Interactions API returns closed immediately, but the Quality backend doesn’t expose the record until the final analytics payload hashes through the regional cache. You can resolve it by adjusting the request flow and explicitly mapping the interaction metadata.
Step one is verifying the payload structure against the Quality schema. The POST /api/v2/quality/evaluations endpoint drops requests that omit the exact channel identifier. You need to hardcode interactionType to "chat" and include a valid wrapUpCode. Leaving that field null forces the validator to check the live interaction state, which triggers the 400 response during the sync window. It’s a common tripwire for bulk jobs.
{
"interactionId": "your-interaction-id",
"interactionType": "chat",
"wrapUpCode": "1",
"evaluationFormId": "your-form-id"
}
Step two covers the regional propagation delay. Seoul runs a heavier queue for digital channels during business hours. If the bulk job fires three minutes after closure, the record usually sits in a pending state inside the local cache. Adding a retry mechanism with a 10-second backoff gives the quality:evaluation:write service enough time to index the chat. You’ll see the status flip to available once the hash completes.
Step three involves checking the OAuth grant. The token requires interaction:chat:read alongside quality:evaluation:write. If the integration user only carries the base interaction:read scope, the Quality endpoint rejects the call with that exact validation error. Pull the token payload and verify the scope array matches both permissions. Missing that second scope breaks the chain every time.
Run the adjusted payload through the sandbox first. The sync window shifts when traffic spikes. Hardcoding a retry delay keeps the bulk job from choking on transient states. You’ll save yourself a lot of headache.
Problem
The validator rejects the request because the evaluation payload is missing the correct segment identifier for digital channels. Voice interactions rely on the interaction ID alone, but chat sessions require the specific segmentId to resolve the transcript data. The sync gap theory is plausible, but this schema mismatch triggers the same interaction_unavailable response code. Real pain point when migrating from voice logic.
Code
You’ll need to extract the segment ID from the interaction details before building the evaluation object. Here’s how to query it in Python before hitting the Quality endpoint:
interaction = platformClient.get_interactions_api().get_interaction(interaction_id)
segment_id = interaction.segments[0].id
# Use segment_id in your POST /api/v2/quality/evaluations payload
Error
If you skip this step, the API returns a 400 status because it can’t locate the transcript bucket. Always verify the segment structure matches the interaction type before submitting the evaluation.
Question
Check if your script is passing a null segment ID. That’s usually the culprit here.