WEM Evaluation Form - Script Error & 400 on /api/v2/wfm/evaluation/forms

Hey all,

Running into a weird one with evaluation forms and the WEM API. We’re trying to push a new form through, it’s pretty standard stuff - a few multiple-choice questions, a text field. But when we hit the POST endpoint, it’s choking.

The SDK version we’re on is v2.13.0, and it’s happening in our Berlin environment. In CIC we used to just build these forms directly in the admin interface and never had this much trouble, but I guess things are different here. The form does build successfully in the UI, but the API call is where it’s falling apart.

The error is a 400 Bad Request, with this payload:

{
 "message": "Invalid request body",
 "code": 400,
 "entityId": "b6f8a7d9-7b2d-429a-8617-5e046d30a4f8",
 "details": [
 {
 "field": "questions",
 "message": "Question 'q1' is missing required property 'type'",
 "code": 400
 }
 ]
}

We’re sending the questions array like this - it looks right to me, the ‘type’ field is definitely there. I’ve even tried stringifying the payload to see if it was a serialization issue, but no luck. I suspect it’s not actually the ‘type’ field itself, but something about how it’s defined.

The Architect flow is pretty basic, just a trigger that kicks off the evaluation and calls the API. Nothing special there. I checked the documentation on the evaluation forms API endpoint (/api/v2/quality/forms/evaluations), and it’s a bit vague on the exact structure required for the questions.

Has anyone else wrestled with this? It’s driving me up the wall. I feel like I’m missing something obvious. The same payload works fine for a simpler form with just one question. This one has 3, and the API is throwing a fit.

The 400 error usually means the request body doesn’t match what the API expects. Is it a schema mismatch? Definitely. The endpoint you’re hitting is wrong- it should be /api/v2/quality/forms/evaluations for creating forms, not a /wfm/ path. Using the wrong base path will just bounce back a bad request every time!!

Option A is to switch the endpoint to the quality path and double check the JSON structure. This is the fastest fix since it’s just a URL change. Option B is to use the SDK’s built-in methods for quality forms instead of raw REST calls. The SDK handles some of the boilerplate, but it can be clunky if you’ve already got a custom JSON payload ready to go. I’d go with Option A if the payload is already built.

The earlier reply is correct. The path must be /api/v2/quality/forms/evaluations. It’s like a wrong SDP offer in SIP negotiation, the server just rejects it. Is the body JSON format correct?

POST /api/v2/quality/forms/evaluations
{
 "name": "Quality Form",
 "questions": [
 {
 "text": "Question 1",
 "type": "MULTIPLE_CHOICE"
 }
 ]
}

The 400 is definitely a path mismatch. The server can’t route the request to a WFM endpoint when it expects a Quality resource.

1. Use POST /api/v2/quality/forms/evaluations for the create call. 2) Double check the JSON body for any nulls in the required fields. Took like 10 mins to verify this in a test org.

The redirection of a request to an incorrect endpoint is analogous to a routing error in the Internet Protocol layer where a packet is delivered to a host that lacks the listening socket for that specific port. The server receives the transmission, but because the resource path does not map to a valid controller, it returns a 400 Bad Request or 404 Not Found. It’s a failure of the initial handshake between the client and the Application Programming Interface.

Correcting the path to POST /api/v2/quality/forms/evaluations should resolve the routing failure. If the 400 error persists after the path correction, the issue likely resides in the payload schema.

Example request structure:

POST /api/v2/quality/forms/evaluations
{
 "name": "Customer Satisfaction Survey",
 "questions": [
 {
 "text": "Was the issue resolved?",
 "type": "MULTIPLE_CHOICE",
 "options": ["Yes", "No"]
 }
 ]
}