Fixing "The REST API encountered an error"

"The REST API encountered an error" means WordPress tried to reach its own internal API at yourdomain.com/wp-json/ and got blocked before a valid response came back. It's not a WordPress core bug: something between the request and WordPress, usually a plugin, a malformed .htaccess rule, or a security tool, is intercepting it. Check these three causes in order.

Start by checking the URL directly. Visit https://yourdomain.com/wp-json/ in a browser. You should get a JSON response listing your site's routes. If you get a 403, a 500, or a blank page instead, that confirms something is blocking the endpoint before WordPress even loads it, and narrows down which fix applies.

Cause 1: a security plugin or firewall rule is blocking wp-json

Security plugins (Wordfence, iThemes Security, All In One WP Security, and similar) commonly include a "disable REST API" or "block XML-RPC and REST API" toggle, sometimes enabled by default in a hardening wizard.

• Go to the plugin's firewall or hardening settings and look for anything mentioning "REST API," "wp-json," or "API access."
• Temporarily deactivate the plugin and reload /wp-json/. If it starts working, you've found the source.
• Re-enable the plugin and turn off only the REST API restriction, rather than leaving the whole plugin disabled.

If you're not sure which plugin is responsible and there are several active, deactivate all plugins via FTP or the file manager by renaming /wp-content/plugins/ to /wp-content/plugins.bak/, confirm the REST API works, then restore the folder and re-enable plugins one at a time until the error returns. This is the same isolation method used for the white screen of death.

Cause 2: a broken or overly strict .htaccess rule

WordPress's REST API relies on pretty permalinks, which route through .htaccess. If a rule was added to block XML-RPC or restrict access by IP or user agent, it can accidentally catch /wp-json/ requests too.

• Open .htaccess via FTP or the file manager (it's in your site's root, next to wp-config.php).
• Look for any block referencing wp-json, xmlrpc.php, or generic RewriteRule deny patterns.
• Comment out (add # at the start of the line) any rule that looks like it targets the REST API or applies broadly, then reload /wp-json/ after each change.

If you're not sure the file is even the issue, rename it to .htaccess.bak temporarily and let WordPress regenerate a clean default: go to Settings → Permalinks in wp-admin and click Save without changing anything. That rewrites .htaccess from scratch using WordPress's defaults, which resolves REST API errors caused by stray rules without hunting through the file by hand.

Cause 3: a plugin or theme is fataling before the API responds

Sometimes the block isn't intentional. A plugin's REST API hook throws a PHP error, and instead of a JSON response you get a fatal error page or a blank result, which WordPress reports generically as "the REST API encountered an error."

• Turn on debug logging in wp-config.php:

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

• Reload /wp-json/, then check /wp-content/debug.log for a fresh entry. The stack trace will name the plugin or theme file that's failing.
• If the log points at a specific plugin, deactivate it and retest. If it points at your theme's functions.php, check any custom REST API code you or a developer added there.

This is the same debug-log approach used for the database connection error and other silent WordPress failures: turn on logging, reproduce the error, read the log.

If none of these fix it

Rule out a PHP version mismatch next. An outdated plugin can fail specifically on newer PHP. As a temporary diagnostic step only, try switching to an older PHP version for your domain to see if the error clears; if it does, the plugin needs an update rather than a permanent version downgrade.

If you've gone through all three causes and the REST API is still failing, open a support ticket from the portal. Include the exact error text, whether /wp-json/ loads directly in a browser, and any debug.log entries you found, along with what you've already tried.