Fixing the WordPress REST API 404: How to Resolve 'rest_no_route'

TL;DR: The 60-Second Fix

In roughly 90% of cases, this error occurs because your WordPress rewrite rules are out of sync or your permalinks are still set to 'Plain'.

• Log in to your WordPress Dashboard.
• Navigate to Settings > Permalinks.
• Select Post name (or any option other than 'Plain').
• Hit Save Changes.

This simple action flushes your rewrite rules. Refresh your API endpoint; it usually starts working immediately.

Why is this happening?

When you request a resource like /wp-json/wp/v2/posts and receive a rest_no_route response, it means the server is alive, but WordPress is lost. It can't map your URL to a specific function.

{
    "code": "rest_no_route",
    "message": "No route was found matching the URL and request method",
    "data": {
        "status": 404
    }
}

This failure typically stems from one of three bottlenecks:

• Disabled Pretty Permalinks: The REST API relies on the /wp-json/ slug, which doesn't exist under 'Plain' settings.
• Web Server Routing: Nginx or Apache isn't handing the request off to index.php correctly.
• Method Mismatch: You are trying to POST data to an endpoint that only accepts GET requests.

Fix 1: Server-Level Configurations

For Apache Users

Ensure your .htaccess file exists in the root directory (usually /var/www/html/). It must contain the standard WordPress routing block. If this file is missing or lacks write permissions, the API will fail.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Check your virtual host file. If AllowOverride is set to None, Apache will ignore your .htaccess entirely. Change it to AllowOverride All.

For Nginx Users

Nginx doesn't recognize .htaccess. You must explicitly tell it how to handle requests that don't match a physical file. Open your site config (often found in /etc/nginx/sites-available/default) and look for the location block:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Run nginx -t to check for syntax errors, then restart the service with systemctl reload nginx.

Fix 2: Debugging Custom API Routes

Are the default endpoints working while your custom ones fail? The issue likely lies in your register_rest_route logic. A common trap is forgetting to wrap the registration in the rest_api_init hook.

add_action( 'rest_api_init', function () {
  register_rest_route( 'myplugin/v1', '/data', array(
    'methods' => 'GET',
    'callback' => 'my_awesome_func',
    'permission_callback' => '__return_true',
  ) );
} );

Check your HTTP methods. If you defined the route as GET but your JavaScript fetch() call is sending a POST, WordPress will return a 404 rest_no_route. Double-check that your URL matches the namespace exactly: yoursite.com/wp-json/myplugin/v1/data.

Verification and Testing

Check the API base to see if it responds at all. Use your terminal to run a quick header check:

curl -I https://yourdomain.com/wp-json/

A HTTP/1.1 200 OK response means the API is healthy. If you see a wall of messy JSON, use a JSON Formatter to inspect it. This often reveals hidden PHP notices or warnings that are breaking the JSON structure and confusing your frontend application.

Common Pitfalls to Watch For

• Security Plugins: Tools like 'All In One WP Security' or 'Hide My WP' often disable the REST API for non-logged-in users. Check their 'WP REST API' settings.
• Cloudflare Firewall: If you see a 403 or 404 only on production, Cloudflare's WAF might be flagging your API calls as suspicious.
• Trailing Slashes: Some server setups are picky. If /wp-json/my-endpoint/ fails, try /wp-json/my-endpoint (without the slash).
• ModSecurity: On shared hosting, ModSecurity might block wp-json requests. Check your hosting control panel for 'Error Logs' if the problem persists.