WordPress uses the REST API to connect the dashboard, block editor, WooCommerce, mobile apps, and external services with your site. When WordPress reports that “The REST API encountered an error,” an internal request to an endpoint such as /wp-json/ has failed.
The message does not identify one particular problem. A plugin conflict, invalid authentication, broken rewrite rules, firewall restriction, PHP failure, or server configuration issue could be responsible. The most reliable approach is to find the HTTP status and then test the likely causes one at a time.
What the WordPress REST API error means
WordPress checks the REST API under Tools > Site Health > Status. The failed test may include an HTTP status code or a more specific error message.
You can also open the REST API index directly in a private browser window:
https://example.com/wp-json/
Replace example.com with your domain. A working endpoint generally returns JSON rather than a regular web page. The response status can point you toward the source of the problem:
- 401: authentication, login, or security rules are rejecting the request.
- 403: a firewall, security plugin, hosting rule, or permissions setting is blocking access.
- 404: permalinks, rewrite rules, or the REST route may be unavailable.
- 500: PHP code, a plugin, theme, or WordPress configuration is failing.
- 502 or 503: the server, PHP-FPM process, proxy, or hosting layer is not responding correctly.
1. Refresh permalinks and test the endpoint
Incorrect rewrite rules are a straightforward cause of REST API 404 errors. Go to Settings > Permalinks and click Save Changes. You do not need to select a different permalink structure.
Saving the settings refreshes WordPress rewrite rules and may regenerate the relevant server configuration. Test /wp-json/ again, then revisit the Site Health check.
If the endpoint still returns a 404, ask your hosting provider to verify Apache or Nginx rewrite support. On Apache servers, the .htaccess file must contain the standard WordPress rewrite block. Back up the file before editing it manually.
2. Check for a plugin or theme conflict
Security, caching, optimization, membership, multilingual, and API-related plugins can alter or restrict REST requests. A theme or custom plugin can also produce a PHP error while WordPress builds the response.
Use a controlled conflict test
- Create a current backup of your files and database. This cPanel WordPress backup guide explains a practical backup and restore process.
- Temporarily deactivate every plugin.
- Test
/wp-json/and the Site Health check. - If the error has disappeared, reactivate the plugins one at a time.
- Test after each activation until you identify the plugin that brings the error back.
If the dashboard is inaccessible, use your hosting file manager or SFTP. Temporarily rename wp-content/plugins, such as changing it to plugins-disabled. WordPress will deactivate the plugins. Restore the original directory name after testing, then reactivate the plugins individually.
If disabling plugins does not help, switch temporarily to a default WordPress theme such as Twenty Twenty-Four. If the REST API works with the default theme, inspect custom theme code, particularly code connected to REST filters, authentication hooks, or shutdown handlers.
3. Investigate authentication and logged-in requests
Some REST API routes are public, while others require a logged-in user and a valid WordPress nonce. Requests from the block editor, Site Health, and WooCommerce administration can fail when cookies or nonces are invalid.
Log out, clear the site’s browser cookies, and log in again. Test in a private window and temporarily disable browser extensions. Under Settings > General, confirm that the site uses one consistent URL, including HTTPS and the preferred www or non-www version.
Inconsistent HTTP and HTTPS settings can interfere with authenticated requests. If the site was recently moved to HTTPS, update the WordPress Address and Site Address and check that the SSL redirect is not creating a loop.
Do not permanently remove authentication checks to make an endpoint work. Custom REST routes should use permission callbacks and validate user capabilities before returning private data.
4. Review security plugins, firewalls, and hosting rules
A 403 response often means the request is being blocked before WordPress processes it. As a controlled test, place security or firewall plugins in learning mode or temporarily disable them. Review their logs for blocked requests containing /wp-json/, wp-json/wp/v2, or REST-related query strings.
Also check Cloudflare, a web application firewall, ModSecurity, host-level malware protection, and rate-limiting rules. Ask your hosting provider whether it is blocking REST requests, POST requests, JSON or XML content types, or requests from your administrator IP address.
Avoid allowing every request or turning off all security protections as a permanent fix. Whitelist only the required route or rule, and keep authentication and capability checks enabled.
5. Enable temporary WordPress debugging
A 500 response usually requires an error log. Add the following settings to wp-config.php, above the line that says “That’s all, stop editing!”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Repeat the REST API request, then inspect wp-content/debug.log. Look for the plugin, theme file, function, or line number recorded near the time of the failure.
Debug logs can expose sensitive information, so use them temporarily on a production site and disable them after testing. If the log shows memory exhaustion, see this guide to fixing WordPress allowed memory size errors.
6. Check server errors and PHP compatibility
When the endpoint returns 502, 503, or repeated timeouts, the web server may be unable to communicate with PHP. Review PHP-FPM, Apache, Nginx, and hosting error logs. Also confirm that the PHP version is compatible with your WordPress version, theme, and plugins.
Look for exhausted PHP workers, low memory, execution timeouts, and security rules that reject JSON requests. For a deeper server-side investigation, see this guide to fixing WordPress 502 Bad Gateway errors.
7. Use browser developer tools to inspect the failed request
Open your browser’s developer tools and select the Network tab. Reload the affected dashboard screen and locate the failed request. Note its URL, status code, response body, and request method.
This information can distinguish a failed public endpoint from a logged-in request with a missing nonce. It can also reveal an HTTPS-to-HTTP redirect, a CORS-related block, or a request that stopped before receiving a response.
FAQ
Can I ignore a REST API warning if the site looks normal?
Sometimes, but not without checking which feature is affected. A public site may continue to display correctly while the block editor, Site Health, WooCommerce administration, scheduled tasks, or integrations fail.
Should I disable my security plugin permanently?
No. Disable it only as a controlled diagnostic step. If it is responsible, adjust its REST API or firewall rule, update the plugin, or contact its support team.
Why does saving permalinks sometimes fix the problem?
Saving permalinks refreshes WordPress rewrite rules. If the server was not routing /wp-json/ correctly, this can restore the REST endpoint without changing the visible URLs.
What information should I send my hosting provider?
Provide the endpoint URL, exact HTTP status, time of the failure, relevant server log entries, and whether the problem occurs with all plugins disabled. Do not send passwords, API keys, or complete configuration files.
Conclusion
Fixing a WordPress REST API error starts with identifying the status code rather than changing settings at random. Refresh the permalinks, test plugins and themes, verify authentication, inspect firewall rules, and review PHP and server logs. Make one change at a time, keep a backup, and restore normal debugging and security settings after confirming the cause.