rest_no_route in WordPress: correct the API address and method

Read rest_no_route before treating every 404 alike

An editor, form, or integration request returns an object containing the code rest_no_route and status 404. In WordPress core, this means no handler matched the request’s path and HTTP method. The address may be incorrect, the method incompatible, or the route unregistered in the queried installation.

A route is a resource’s logical path in the API. The same route may offer several actions selected by the method: reading, creating, and modifying are not the same request. Copying only the URL into a browser often changes what you are trying to reproduce.

The goal is for the client to call the endpoint actually provided by the site with its intended method. A server-generated HTML “not found” page does not demonstrate this application error. Therefore preserve the exact response body before regenerating permalinks, changing permissions, or reinstalling components. These interventions do not automatically correct an incorrect method or namespace.

Find the request actually sent

Open the browser developer tools’ Network panel, then observe the failing action. For an action that may send a message, create content, or start a commercial operation, use the existing trace; do not repeat production tests. A private copy with external effects disabled is better suited to controlled reproduction.

Record the method, final address, parameters, and response separately. A full export may contain cookies or secrets; prefer a targeted, redacted record. The 404 indication alone is insufficient to distinguish a WordPress routing rejection from an intermediary response.

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.

1. Select the relevant request in Network and note the displayed method, such as GET or POST.
2. Record the domain, path, parameters, and any redirect.
3. Read the response and confirm the exact presence of rest_no_route.
4. Note the time, authenticated or public context, and expected function.
5. Keep these details before changing the client. A GET test elsewhere does not replace the trace of a POST submission.

Find the REST root of the queried site

The usual prefix is /wp-json/, but the address must be discovered on the affected site. A subdirectory installation, plain permalinks, or customization may produce another root. Do not randomly combine the homepage address and core-file address.

WordPress normally exposes a discovery link with the relation https://api.w.org/ in headers or page source. Search the homepage source for that relation and record its associated address. With plain permalinks, it may use ?rest_route=/ instead of the rewritten prefix.

Open only the discovered root of the site you are authorized to examine. It should describe the API rather than show another domain’s content or a hosting login form. If a redirect changes the domain or subdirectory, check the client configuration and the server actually targeted. Do not disable environment protection to make the index public; use the diagnostic access intended for that copy.

On multisite, start from a page of the affected subsite to discover its root. On WordPress.com or a managed platform, use the API actually intended for the integration and available access; do not replace its base with one from documentation for another installation. This client diagnosis does not, by itself, require SSH access.

Compare the route with the installation’s index

The REST index may describe exposed namespaces, routes, and methods. A namespace groups endpoints, such as core resources or a plugin’s endpoints. A route present in documentation is not necessarily available in the component version installed on your site.

In the index response, look for the relevant namespace and path. Some entries contain an expression describing a variable identifier; they are not filenames to find over SFTP. For example, a post route expects a numeric identifier, not necessarily the slug visible in its public address.

1. Identify the correct root, then open its discovery response.
2. Look for the expected namespace and path in the advertised routes.
3. Compare the accepted method with the one recorded in the browser.
4. Check the documentation version used and the installed component version.
5. If the index is filtered or hidden, do not conclude that the route is definitely absent: have the maintainer confirm registration without globally lifting protection.

Use the intended method without turning a read into a write

A URL intended for submission may reject GET while accepting POST. Opening it in the address bar therefore does not test the original submission. Likewise, sending an update to a collection path instead of an item path may match no intended handler.

Consult the exact endpoint’s documentation. In an existing API client or connector, check the method and URL fields together. Do not choose POST merely because it makes the message disappear: on a suitable route, this method may create a resource or trigger a submission.

If a request crosses a redirect, also observe the final request’s method and address. Prefer correcting the client to target the documented canonical address directly. Do not use a method-override parameter to bypass a rule without understanding its effects. The read test below avoids write methods; validating creation or modification must be prepared separately on a copy with designated test content.

Perform a short read without credentials

To distinguish a general addressing problem from a specific route problem, you can read one public post with curl if already available. The examples assume the usual root of an installation at the domain root. Replace the addresses with those discovered for your site; do not apply them unchanged to a site in a subdirectory.

Run both commands separately from a terminal. In Windows PowerShell, use curl.exe instead of curl. They request a reduced public collection without credentials and bound the download duration. An empty list may be normal if no public post matches; it is still different from a route error.

The second form passes the path through rest_route for addressing comparison. If this form works while the first returns an HTML 404 page, examine rewriting. If both work but the plugin fails, focus on its route, method, and context. This check validates neither your write permissions nor availability of a route provided by another component.

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 '_fields=id,link' 'https://votre-site.example/wp-json/wp/v2/posts'
curl -q --include --max-time 20 --get --data-urlencode 'rest_route=/wp/v2/posts' --data-urlencode 'per_page=1' --data-urlencode '_fields=id,link' 'https://votre-site.example/'

Correct the client when the route exists

When the route and method are present on the correct installation, compare their definition with the client’s actual request. An old domain, repeated prefix, obsolete namespace version, or identifier in the wrong place is enough to produce a different request from the intended one.

Keep the connector’s initial configuration privately. Menus vary by software: find its existing connection configuration, then the base URL, path, and method fields. Do not duplicate the REST root if the software already adds it. Nor should you put a secret identifier in the URL to compensate for another failure.

1. Correct only the domain, path, or method whose discrepancy is confirmed.
2. Save configuration on the copy or in its test profile.
3. Perform a documented read without external effects to verify the target.
4. For a write, then use test content and check that no duplicate operation was created.
5. If the result worsens, restore the previous fields. Keep before-and-after evidence instead of simultaneously changing authentication and routing.

Restore the component owning a missing route

If a plugin provides the route, availability depends on its loading and version. In Plugins > Installed Plugins, check the owning component identified by its documentation, its state, and dependencies. Files being present on disk does not prove that it loads for this site or context.

On a backed-up copy, if this component was intended but deactivated by mistake, check its prerequisites and activate only it. Reopen the index and compare the route. If activation causes a critical error, return to the previous state and examine the log; do not activate every component in succession looking for one that restores the route.

If the problem follows an update, compare client and component versions. A removed or renamed route requires a documented client adaptation, not creation of an open route bearing the old name. For custom code, the maintainer must check registration at the intended time, particularly during rest_api_init. Do not modify core files or a third-party plugin to add a handler bypassing its controls.

Check the specifics of a custom content type

Content visible in the dashboard is not automatically exposed through the REST API under the name a connector assumes. Its registration may define REST support and a base different from its public label. A type named “events” in the interface may therefore not use the path guessed from that word.

Consult the settings and documentation of the component declaring this type. Look for its REST support, base, and controller if customized. The maintainer can compare effective registration with show_in_rest and rest_base without immediately changing their values.

Do not enable REST exposure of sensitive content merely to satisfy a tool. Have the intended resources and permissions confirmed. If the correct route exists under another base, correct the client. If support is genuinely missing and must be added, that change requires functional validation and appropriate permissions on a copy. It goes beyond replacing one word in the URL and is not solved by removing server access controls.

Address rewriting only when the comparison points to it

If the rest_route format works and the rewritten path does not reach WordPress, you have a clue about server routing. A JSON rest_no_route object must first be analyzed as an application routing rejection; preserve that distinction before replacing server rules.

On a copy, check the expected address and permalinks. For Apache, applicable rules may reside in site configuration or its permitted .htaccess. On Nginx, changing .htaccess does not have that effect. Use the procedure specific to the identified server instead of a generic rules block found for another host.

Back up rules and check syntax before the administrator applies them. The permalink guide covers this specific repair; the goal here is to provide the comparison justifying it. After the fix, check the canonical REST address and a few normal pages. A rule that repairs the API but breaks media or administration is not complete validation.

Change diagnosis when the response code changes

After correcting the route, another result may appear. A 401 or 403 rejection then concerns identity or permissions, while rest_invalid_param concerns received arguments. These results do not prove that the path change failed: the request may have reached a different stage.

Read the full code and details instead of continuing routing diagnosis out of habit. A well-formed but nonexistent numeric identifier can also produce a resource-not-found error different from rest_no_route. The API has then recognized the path type without finding the requested item.

No new plugin is required to compare address, method, and registered route. A tool globally disabling REST restrictions could instead hide an error or widen access without correcting the client. First use the browser, native discovery, and documented read. Application secrets and revocation belong to a separate, already-available procedure when evidence shows authentication is the actual block.

Check actual operation after the fix

Validate the same operation observed initially, in the same user context and environment. Successfully reading public posts does not guarantee a form or modification will work. It confirms only that this read endpoint works.

On the copy, use test content and disabled external destinations for the previously failing function. If an old attempt may have produced an effect, look for it before repeating the action. An integration automatically retrying its request must resume through its documented mechanism without recreating the same event in parallel.

1. Check the request’s final address and method after the fix.
2. Confirm that rest_no_route disappears from the affected workflow.
3. Read the new result and check the expected effect in the application.
4. Also check a public and an authenticated workflow that worked before the intervention.
5. Archive the redacted record, corrected setting, and planned rollback. Do not treat status 404 disappearing alone as proof of business success.

Return to the previous configuration and prepare next steps

If the fix is unsuitable, restore only the client fields or component you actually changed. For server configuration, have the initial fragment restored, then apply the service-specific check and reload. Do not restore the entire database to undo a simple connection address if no other data changed.

Record the selected REST root, namespace, route, method, and version of the component providing them. This prevents a future domain or version change from leaving an old path in external software. For a custom-built client, request discovery and documented paths instead of always appending /wp-json/ to an assumed address.

To continue with the maintainer, provide the redacted request, exact response, time, and comparison with the index. Add the alternative-format result if tested, along with versions on both sides. Clearly state what was confirmed and what remains a hypothesis. These details enable a targeted client or registration fix without opening the entire API or reinstalling the site.

Observe a minimal route in a laboratory plugin

This exercise is for a private copy and an authorized developer. Create wp-content/plugins/bpc-route-temoin/bpc-route-temoin.php with this content, then activate only BPC Route témoin under Plugins. Do not insert the snippet into core or the plugin whose route is missing.

From the discovered REST root, open bpc-labo/v1/etat. This public read route returns only fixed text without site data. __return_true is suitable only for this deliberate absence of restriction; a private business route must check capabilities and authentication. Compare the namespace, path, and method with those advertised in the index.

This reference case succeeding does not add another component’s missing route. It helps explain where registration should be corrected. Deactivate and delete this laboratory plugin after the exercise; the reference path should disappear. The guide’s curl reads now use -q first to ignore a curlrc file that might implicitly enable redirects.

<?php
/** Plugin Name: BPC Route témoin */
add_action( 'rest_api_init', function () {
    register_rest_route( 'bpc-labo/v1', '/etat', array(
        'methods'             => 'GET',
        'permission_callback' => '__return_true',
        'callback'            => function () {
            return rest_ensure_response( array( 'etat' => 'ok' ) );
        },
    ) );
} );