Skip to content

Debugging 400 Malformed Requests

A 400 response means the server couldn't parse the request. Almost always, this is an unconfigured dynamic field: a value that should have been extracted from a previous response is being sent as a stale recorded literal, and the server rejects the resulting payload as malformed. Less common causes: missing required fields that were present during recording, type mismatches (the server expects a JSON number but the test case sends a string), or URL encoding issues with special characters.

Symptom

Visual indicators:

  • Replay View: Failed transaction shows 400 status code
  • Content View: Response shows "Bad Request", "Invalid request", or "Malformed syntax"
  • Headers View: Request body or query parameters contain values that look stale

The clue is usually in the response body. Servers often return a specific error like "Invalid order_id format" or "Missing required field: state_token" along with the 400. Read it.

Diagnostic Steps

  1. Open the Content View for the failed 400 transaction and read the response body. Servers usually name the offending field.
  2. Open Headers View and find that field in the request body. Note its value.
  3. Compare against the recorded value: open the same transaction in the recording view (not the replay view). If the values match exactly, ASM didn't correlate the field. That's an unconfigured dynamic field.

Solutions

Fix 1: Re-Run ASM

If ASM hasn't been run, or hasn't been re-run since the test case was modified, run the Configure for Replay wizard. For ASM-only re-runs, use Right-click → Configure → Application State...

Fix 2: Create a Custom Extractor

If ASM ran but didn't catch the field the server is complaining about, the value probably uses a non-standard pattern. Create a custom extractor on the response that contains the value, and wire the failing transaction's field to read from that variable.

Fix 3: Inspect for Encoding or Type Issues

If the field is correctly configured as dynamic but the server still returns 400, check:

  • URL encoding: Are special characters in the value being encoded correctly? Compare the raw request body of the recording and the replay for differences.
  • Type: Does the server expect a number where the test case is sending a quoted string?
  • Required field: Did the recording include a field the replay isn't sending? Sometimes the application's UI emits a field that the recorder didn't capture (computed at the last moment by JavaScript, for example).

Still Failing?

Ask the AI

Replay fails with 400 on POST /api/orders. The response body says
"Invalid customer_id format." The customer_id in the request looks
like the recorded value. How do I fix this?