rest_invalid_param in WordPress: correct the data sent to the API

Distinguish a rejected argument from an inaccessible API

WordPress returns the code rest_invalid_param, generally with status 400 and the name of one or more parameters. The request encountered a check on its data. The API may be accessible and the route correct while rejecting a value, structure, or condition expected for this operation.

This differs from rest_no_route, which concerns the path and method, or an HTML response received instead of expected JSON. It also differs from a JSON document that cannot be parsed. Therefore do not change permalinks or hosting before reading the rejection details.

The goal is to make the request match the endpoint’s contract: its address, method, arguments, and constraints. It is not to remove validation so any data is accepted. We will first read the rejected argument, then examine the request actually sent and correct its source. If another code explains a permissions issue, retain that signal instead of arbitrarily changing content.

Read params and details in the response

In the browser’s Network panel or the API client being used, open the failed request’s complete response. The general message may mention only the parameter name. The data.params and, when supplied, data.details fields give more precise information about the failing check.

Record the exact name, including any nested property. A value outside an allowed list, a wrongly structured object, and a prohibited status require different fixes. Not every endpoint provides the same detail level; the absence of a subcode does not demonstrate that the client is correct.

In Chrome, open the ⋮ menu > More tools > Developer tools, then the Network tab. Select the request: Headers contains the address and method; Response contains the returned body; Payload shows submitted parameters. If the request was not recorded, prepare reproduction without external effects on the copy before retrying. A Fetch/XHR filter may help, but remove it if the request you need is a navigation.

A missing required field may produce rest_missing_callback_param, and unreadable JSON may produce rest_invalid_json: preserve their own codes. For rest_invalid_param, details depend on the check rejecting the value. A generic message therefore does not authorize inventing a constraint absent from documentation.

1. Confirm the response’s main code and status.
2. Record names in params without copying associated secrets or personal data.
3. Read every available detail and distinguish type, value, unknown property, and permissions restriction.
4. Note the request URL, method, and time.
5. Keep the initial record before changing a field. The PHP log may stay empty if WordPress simply returned an expected validation error.

Observe the data actually transmitted

An interface may display a readable value while the connector sends something else: translated text, an array converted to a string, or an old value retained in a request template. The visible form therefore does not fully describe the request WordPress receives.

In Network, open the URL parameters and Payload area or form data. Compare the field name, value, and location. In an external client, examine its final request or redacted log instead of only the starting configuration. Full exports may contain credentials, private content, and authentication headers.

For a write operation, use the existing trace first. Subsequent tests must be prepared on a private copy with payments, emails, and external automations disabled. Even if validation rejection should stop the intended action, do not assume that no effects occurred elsewhere in the software or during a previous attempt. Check the resource state before repeating a request that could create or modify it.

Compare the correct endpoint’s arguments

The schema describes accepted data, its types, and some constraints. Use documentation for the route and method actually called, in the installed version. Collection-read arguments are not automatically those for creating or updating.

REST discovery and route information can help identify exposed arguments. Some descriptions are filtered or incomplete; for a custom component, the maintainer must then confirm effective registration. Do not copy rules from another plugin simply because both objects have the same interface name.

On multisite, consult the targeted subsite’s contract; its components may differ from another network site’s. On a managed platform or WordPress.com, also confirm which API the connector should use. Server-file access is not required to correct an argument produced by an already-configurable client.

1. Confirm the request’s root, namespace, path, and method.
2. Open the reference matching this operation and version.
3. Find the parameter named in the error, its permitted values, and its conditions.
4. Compare this information with data observed in the final request.
5. If client and server describe different contracts, keep their versions and find a compatible combination before changing the schema.

Correct an out-of-list value without translating its technical identifier

Some arguments accept only a specific list of values. For example, core post reading provides technical sort keys. A French interface may display “date” or “titre,” but the client must send the expected technical value, not an improvised translation or another API’s column name.

If the response says orderby is not among allowed values, compare its list with the collection reference. For core posts, date is a documented sort value. This choice is not universal for every plugin route: use that route’s own contract when querying another resource.

In the connector, correct the sorting setting or request template at the point producing this value. First back up its private configuration and do not change the data source, account, and address simultaneously. If the software generates an invalid value itself without a user setting, keep the request and versions for its vendor; manually replacing each request does not fix the mechanism recreating them.

Validate a small compliant read before the full workflow

The check below reads one public post sorted by date from the usual core endpoint. Replace the address with the REST root actually discovered for your installation; a subdirectory site or plain permalinks require an adapted address. This command does not target a custom route for you.

Run it with curl if already available, or curl.exe in Windows PowerShell. Parameters are encoded separately, duration is bounded, and no credentials are supplied. An empty list may be normal. What matters for this check is distinguishing a valid collection response from a new route, permissions, or argument rejection.

Success shows that this small compliant read works. It does not automatically validate the whole connector, its writes, or custom fields. If the initial error concerns another property, apply the same comparison to that property’s schema instead of concluding that everything is fixed. Keep before-and-after traces, then return to the original workflow on the prepared copy.

The --include option also displays status and headers before the body. Redirects are not followed automatically: examine the destination and correct the called base if necessary. Keep this output private and redact any cookies before sharing. A protection rejection on the copy must be handled through its intended access without making the copy public.

curl -q --include --max-time 20 --get --data-urlencode 'per_page=1' --data-urlencode 'orderby=date' --data-urlencode '_fields=id,date' 'https://votre-site.example/wp-json/wp/v2/posts'

Preserve the expected types and structures

A string, number, array, and object do not represent the same structure. A connector may transform an identifier array into comma-separated text or send a nested object as a string containing JSON. The screen then looks correct, but the server does not receive the intended form.

Compare the contract with the structure actually sent. Accepted conversions depend on the endpoint and its sanitization functions; it would be false to claim that WordPress always rejects every quoted numeric value. Do not base diagnosis on that general rule. Instead retain a minimal passing example and the exact difference from the failing one.

For a property expected to be an object, check its keys and their types at the appropriate level. For an array, check its element types and stated limits. In the client, use the input mode or mapping appropriate to the format instead of manually concatenating fragments. If automatic conversion is needed, implement it in the producing component and also test empty values and intended edge cases.

Distinguish JSON format from validated content

A document may be syntactically valid JSON while containing data rejected by the API. Conversely, a missing comma or incorrect quotes may prevent parsing before field validation. Core has a separate code, rest_invalid_json, for this type of defect when the body is interpreted as JSON.

Also check the content type declared by the client and its sending mode. A body built as form data does not automatically become a JSON object because a header was renamed. In an existing connector, choose the documented format, then examine the final request to confirm the tool actually produced it.

Do not paste private content into a public validator to solve a syntax problem. Use a trusted editor or local check and a redacted copy. Successful syntax validation tests neither permissions nor the endpoint schema. After the fix, reread the new response code: moving from a parsing error to a rejected argument indicates a different stage that must be analyzed separately.

Remove a contradictory value from multiple sources

The same name may appear in the path, URL, form data, and JSON body. WordPress has a priority order for retrieving parameters, and this order can be customized. Correcting the visible URL value is therefore insufficient if another source continues supplying the same name with a different value.

In client configuration, search for parameters inherited from a profile, template, or environment variable. Then inspect the final request instead of assuming a field removed on screen has disappeared from transmission. An old body saved in the software may still contribute.

1. Search for the rejected name in every data source of the observed request.
2. Identify the source intended by the client and API documentation.
3. On the copy, remove only duplicate settings identified as contradictory.
4. Resend a controlled request and check the final value and response.
5. If nothing changes, restore the initial profile and have the effective mapping examined. Do not change the server’s global priority order to conceal a local client defect.

Isolate a property added by a component

A plugin may add properties or change how a client builds its request. An object may then contain a field the active schema does not accept. Additional-property rules depend on the schema; not every unknown argument in every request is necessarily rejected in the same way.

If details name a prohibited property, identify the component adding it and the one defining the contract. Compare their versions and the chronology of the problem’s appearance. The property name may guide investigation, but its presence alone does not establish which product is at fault.

On a backed-up copy, return to a documented compatible configuration or isolate only the component confirmed to participate in building the request. Preserve content and settings linked to this field before removal. If the defect comes from a specific version, find its official fix and validate it on the copy. Do not erase every database metadata value or modify core to accept the property: these actions may delete data or weaken the contract without addressing the cause.

Respect a detail indicating a permissions restriction

The main code may be general while its detail describes a status or context prohibited for the account used. In that case, sending better-formed text does not automatically grant permission to retrieve or modify the resource. Therefore read the subcode and reported condition before deciding to loosen the schema.

Check the account actually recognized by the integration and the operation it is meant to perform. Public read access does not permit requesting the same information as a maintenance account. Correct the request scope or legitimate authorization according to the need, without routinely assigning an administrator role.

No new plugin is needed to examine a response and correct mapping. A tool forcing argument acceptance or disabling access checks may conceal the error while producing an incorrect result. If evidence points to authentication or capabilities, use the corresponding guide and retain the parameter record for context. The goal remains an authorized, compliant operation, not just a response without an error message.

Validate the obtained data and intended effect

An error-free response does not guarantee that the client sent the intended meaning. A removed value may have been replaced by a default, or an incorrect field may have been ignored. Therefore check the functional result: chosen sorting, selected resource, or saved data, according to the operation.

For a write on the copy, use test content and check its values after the request. Verify that it did not already exist and that no event was triggered twice. In production, resume only through the maintenance mechanism validated for this integration, retaining evidence of the intervention.

1. Resend the corrected request in the prepared context.
2. Reread the code, status, and any remaining details.
3. Check the value actually returned or saved, not just the disappearance of the message.
4. Try another representative case already covered by the contract without introducing a new business operation.
5. Archive the client difference, versions, and result. If another parameter is rejected, handle it separately instead of progressively removing every field until an empty response is obtained.

Undo the change and document the chosen contract

If the modified setting produces an incorrect result, restore the client’s initial mapping or profile. For a component updated on the copy, use its consistent backup and planned rollback procedure. Do not restore the entire production database to undo a simple argument value in external software.

Keep a minimal redacted working example and the rule it checks: permitted value, object structure, transfer format, or parameter source. Associate it with the endpoint and client versions. The same example may become invalid if the contract changes; it must not be presented as permanent authorization to bypass checks.

To hand over a remaining defect, provide the route, method, versions, rejected name, subcode, and redacted request structure. State whether the small reference read works and how it differs from the full workflow. This information helps the vendor or maintainer reproduce the defect without receiving your secrets or visitor data. A lasting fix must address the request producer or a justified contract change, then be verified in the actual workflow.

Compare a rejected request with its minimal correction

For core’s posts collection, a client sending orderby=plus-recent transmits an interface label instead of the expected technical value. The correction is to send orderby=date and, if descending order is intended, order=desc. Correct these fields in the connector producing them, then reread the final request. An empty list remains possible: it does not mean the argument is invalid.

For structures, use the exact route’s schema. A JSON identifier array is written, for example, as [12, 34], not necessarily the text "[12, 34]". A nested object must remain an object if the contract requires it. These examples illustrate types; they are not universal parameters to add to every WordPress request.

Keep three elements: the redacted initial value or structure, rejection details, and the corrected request with its business result. Do not reconstruct an “expected” JSON response in place of the one actually received, because details vary among validators. If the request has duplicates in the URL and body, correct the producer before blaming the server. The -q option added at the beginning of the curl check neutralizes its personal configuration to preserve observation of the first response.