422 Unprocessable Entity Error: Causes and How to Fix It

You submit a form, save a block in the editor, or hit an API endpoint from your app — and instead of the expected response, you get a 422 Unprocessable Entity. The request went through fine, the server understood it, but it's refusing to act on it. Here's what's actually happening and how to run it down.

What a 422 Actually Means

A 422 is different from most other 4xx errors, and that difference matters when you're debugging it. A 400 Bad Request means the server couldn't even parse what you sent — broken JSON, a malformed header, garbage syntax. A 422 means the opposite: the syntax was fine, the server read it perfectly, but the content failed validation. Wrong data type in a field, a missing required value, a date that doesn't exist, an email that isn't shaped like an email.

Think of it as the difference between a sentence that's grammatically broken and a sentence that's grammatically correct but makes no sense. 400 is the first. 422 is the second.

422 vs the Other Codes You Might Be Confusing It With

If you're only ever seen 400 and 500 before, 422 can be confusing the first time — the request "looks right" to you, but some validation rule inside the app disagrees.

Where 422 Shows Up Most on WordPress and Hosted Sites

1. WordPress REST API and the block editor

Gutenberg saves posts through wp-json/wp/v2/posts. If a block sends a malformed meta value, an invalid taxonomy term ID, or a featured image ID that doesn't exist, the REST API rejects it with a 422 and a JSON body describing which field failed.

2. WooCommerce checkout and cart endpoints

The Store API (wp-json/wc/store/v1/...) validates every field on checkout — shipping address format, required billing fields, valid country/state combinations, quantities against stock rules. A plugin that alters checkout fields without updating validation rules is a common cause here.

3. Custom API integrations

If you're calling a third-party API from a script, webhook, or app hosted on your VPS, a 422 usually means the payload structure matches what the API expects, but a value is out of range, a required field is empty, or an enum value isn't one of the accepted options.

4. Contact form plugins

Contact Form 7, WPForms, and Gravity Forms all submit via AJAX or the REST API in their newer versions. A required field left empty, a file that fails the type/size check, or a reCAPTCHA token that expired mid-submission can all surface as a 422 instead of a friendly on-page error if a caching or security plugin interferes with the AJAX response.

5. File uploads

Uploading a file through the Media Library REST endpoint or a custom uploader with the wrong MIME type, an oversized file, or a filename with disallowed characters often comes back as 422 rather than 413 — the request itself was fine, the file just failed content rules.

How to Diagnose It

Don't guess — read the response body. A 422 almost always comes with a JSON payload naming the exact field and rule that failed.

1. Open browser dev tools → Network tab before reproducing the error. Click the failed request, check the Response tab, not just the status code.
2. Reproduce with curl if it's an API call, so you can see the raw response without the browser stripping anything:

   curl -i -X POST https://example.com/wp-json/wp/v2/posts \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer YOUR_TOKEN" \
     -d '{"title":"Test","status":"publish"}'

3. Check the error code inside the body, not just the HTTP status. WordPress REST errors look like:

   {
     "code": "rest_invalid_param",
     "message": "Invalid parameter(s): status",
     "data": {
       "status": 422,
       "params": {"status": "status is not one of publish, future, draft, ..."}
     }
   }

   That params object tells you exactly which field to fix.
4. Enable WP_DEBUG in wp-config.php temporarily if the 422 is coming from your own site's PHP rather than an external API:

   define( 'WP_DEBUG', true );
   define( 'WP_DEBUG_LOG', true );
   define( 'WP_DEBUG_DISPLAY', false );

   Check wp-content/debug.log afterward for the validation failure.

Fixing It by Cause

REST API / Gutenberg

• Confirm the field values match what the schema expects — status must be one of the registered post statuses, taxonomy term IDs must actually exist, dates must be valid ISO 8601.
• If a plugin registers custom REST fields, check its register_rest_field() call for an overly strict validate_callback that's rejecting valid input.
• Deactivate recently added plugins one at a time and retry the save — a plugin hooking into rest_pre_insert_post is a common culprit.

WooCommerce checkout

• Check that address/state fields match WooCommerce's expected format for the selected country — a state code like "CA" needs to match WooCommerce's internal list, not a free-typed value.
• Test checkout with a default WooCommerce theme (Storefront) and no other plugins active to isolate whether a checkout-field plugin is the source.
• Update WooCommerce and the payment gateway plugin — validation rule mismatches between an old gateway plugin and a newer WooCommerce core are common after only one side gets updated.

Custom API calls

• Read the API's documentation for that specific endpoint's required fields and allowed value ranges — 422 responses from most well-built APIs include a machine-readable error list, so log the full response body, not just the status code.
• Watch for type mismatches — sending "5" (string) where the API expects 5 (integer) fails validation on stricter APIs even though it "looks" correct.

Contact forms

• Test the form with browser caching disabled and any page-caching plugin's exclusion rule applied to the form page — a cached nonce or stale AJAX URL causes validation failures that look like a 422.
• Check the plugin's error log (most have one under their settings) for the specific field that failed.

Prevention

• Keep WordPress core, WooCommerce, and any REST-API-dependent plugins on the same update cadence — validation schemas drift when one side updates and the other doesn't.
• When building custom integrations, validate and log the request payload on your side before sending, so you catch bad data before the remote API rejects it.
• Exclude checkout, cart, and API endpoints from page-caching and minification rules — a minifier that touches a JSON payload or an AJAX URL is a frequent, hard-to-spot cause of 422s.
• If you maintain a custom REST endpoint, return a clear params breakdown in your 422 responses — future-you debugging this at midnight will be grateful.