How to Fix WordPress REST API Disabled Error (Step-by-Step

The “REST API disabled” message signifies a broken communication bridge between your site’s backend and front-end. This error results from an over-protective security plugin, lost permalinks configuration, or a server-level firewall intercepting JSON payloads. Systematically addressing these specific causes will resolve the issue and restore full functionality to your content.

To fix the primary issue, start by logging into your admin dashboard. Navigate to your Settings and find the Permalinks section; simply click “Save Changes” at the bottom of the page without changing any actual settings. This action forces WordPress to flush its rewrite rules and refresh the API paths. Next, audit your security plugins. Many popular security suites have a specific setting that limits REST API access for non-logged-in users—you will want to ensure this isn’t blocking the functions required by your editor or other integrated tools.

Emergency Stop-Gap: If you are currently locked out of the Gutenberg editor because of this error, we need to bypass the dashboard entirely to fix the configuration. Log into your site via FTP or use the File Manager provided by your hosting provider. Navigate through the directory to wp-content/plugins/ and rename the folder of your active security plugin (for example, change wordfence to wordfence_old). This will force WordPress to deactivate the plugin immediately, restoring your access so you can log in and fix the settings from within the dashboard.

Before You Start

Your site is currently offline or malfunctioning, and I know how much pressure you are under right now—but this is a fixable issue. Before we touch any files, you must back up your entire website. This includes performing a full file backup via FTP and a complete database export through phpMyAdmin or a migration plugin. Because even minor errors in .htaccess or wp-config.php can lead to an immediate lockout from your site’s administrative area, having these backups is your safety net. Ensure you have your hosting control panel credentials (cPanel, SiteGround, etc.) and an FTP client ready before we proceed with any changes.

Related guide: Fix GoDaddy Managed WordPress Migration Failure

Why is the REST API showing a disabled error?

The WordPress REST API acts as the primary communication channel between your site’s core and its front-end features. Since the introduction of the Gutenberg Block Editor, this connection has become a vital backbone; it allows blocks to fetch data, save content, and communicate with the database in real-time.

When you see a “disabled” error, it rarely means WordPress has actually turned off the feature on your end. Instead, it usually indicates that something is standing in front of the bridge and blocking the traffic from passing through. This blockage typically occurs at one of these three distinct levels:

1. The Application Layer: A security plugin (common examples include Wordfence or iThemes Security) may be over-eager. It identifies an incoming API request as a “bot” attack and blocks it automatically to protect your site.
2. The Configuration Layer: This often stems from how your permalinks are set up. If they are set to “Plain” instead of “Post Name,” the .htaccess file cannot correctly route REST API requests, leading to a failure in communication.
3. The Server Layer: In some cases, the block happens before the request even reaches your WordPress installation. A server-level firewall, such as ModSecurity, may detect a JSON payload and flag it as a potential injection attempt, stopping the traffic at the “front door.”

Related guide: Fix WordPress Critical Error

How do I fix permalink issues that block the REST API?

When you encounter an error stating that features are “disabled,” it is rarely a failure of your plugins or theme. Instead, these issues are typically caused by broken rewrite rules—the internal map WordPress uses to connect your URLs to your content. If this map isn’t updated, the site loses its way when trying to locate the /wp-json/ path.

You won’t need to log into your server or manually edit any configuration files to resolve this. We can fix it by forcing WordPress to regenerate the .htaccess file (or the equivalent configuration if you are running on Nginx).

1. Log in to your WordPress admin dashboard.
2. Navigate through the sidebar menu to Settings > Permalinks.
3. Do not change any settings on this page.
4. Click the Save Changes button at the bottom of the page.

This action flushes the rewrite rules and updates how the server interprets your URL structure. It is the most common fix for Gutenberg errors where blocks fail to load or “save” content because the backend communication has been interrupted.

Related guide: WordPress White Screen of Death Recovery Service

Is my security plugin blocking the connection?

It is very common for security plugins to act as a gatekeeper that is simply too strict, blocking legitimate traffic while trying to stop bad actors. These tools are designed to be your first line of defense, but they can sometimes become over-aggressive and cut off the connections your site needs to function correctly. Many popular plugins include specific toggles to disable the REST API for users who aren’t logged in; this is intended to stop hackers from “scraping” data, but it often catches legitimate requests in its net.

If you are running Wordfence, Sucuri, or a similar security suite, you need to inspect those specific firewall settings:

1. Navigate to your Security Plugin’s main dashboard.
2. Locate the section labeled WordPress Integration, Firewall Settings, or REST API.
3. Ensure that the “Disable REST API” option is unchecked.
4. If you are specifically using Wordfence, check both the “Learning Mode” and the “Brute Force” protection settings to ensure they aren’t flagging or blocking wp-json calls.

How do I check for server-side blocks like ModSecurity?

If you have already addressed your permalinks and audited your plugins but the error remains, the issue likely stems from a server-level firewall. ModSecurity is a common module used to detect suspicious patterns in web requests. Because REST API calls are transmitted as JSON, they can sometimes be flagged as “code” by security rules that haven’t been properly tuned.

To diagnose this:

1. Access your hosting control panel and find the Error Logs section.
2. Look for entries containing 403 Forbidden or 401 Unauthorized associated with the /wp-json/ path.
3. If you see these, contact your host’s support team and tell them: “I am getting a 403 error on my wp-json calls. Can you check if ModSecurity is blocking these specific requests?”

How do I fix this via FTP or File Manager?

When you find yourself locked out of your dashboard or the “Save Permalinks” method fails to clear the error, we need to move into manual territory. This means accessing your site’s core configuration files directly through an FTP client or a File Manager tool provided by your hosting account. It’s a common hurdle, and we can get it straightened out by looking at these two specific files.

Editing the .htaccess file

For Apache servers—which power the vast majority of WordPress installations—the .htaccess file acts as the instruction manual for how your server handles traffic. You need to locate this file in your root directory and ensure it contains the standard WordPress block:

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

Once you have this open, scan the area below the END WordPress tag. If there are any extra rules hanging around that mention “json” or “wp-json,” those are likely causing your conflict. Remove those specific lines to ensure the server isn’t blocking your API calls.

Checking wp-config.php

Sometimes a plugin will leave behind a piece of code in your wp-config.php file that explicitly shuts down certain features. We need to scan this file for any lines involving REST_BASE or DISABLE_REST. If you find a line similar to the example below, it is likely the culprit:

// Example of what might be blocking it (remove if found)
define( 'WP_10_REST_API', false ); 

If you locate a line like that, you should remove it entirely or change the value from false to true. For more detailed information on core requirements and system specifications, you can find the full documentation at developer.wordpress.org.

How do I fix it using Command Line Interface (CLI)?

If you have SSH access, we can bypass the standard WordPress dashboard and communicate directly with the underlying server. This is often the most efficient way to clear out stalled cache files and force the system to recognize new rules when the web interface isn’t responding correctly. We will use WP-CLI to perform these specific actions:

Flush the rewrite rules

Run this command from your WordPress root directory:

wp rewrite -1_flush

Check REST API status

We need to determine if the REST API is completely offline or if it is simply a matter of restricted permissions blocking your view. This command will confirm its current state:

wp_json --debug

If you receive a valid JSON response containing information about your site, the API is active and functioning properly. If that happens, we know the issue isn’t with the server itself, but rather a specific plugin or security rule blocking permissions at the application level.

What are the common mistakes that make the problem worse?

I’ve seen many site owners try to patch these issues using quick fixes they find online, only to end up with even more complications. It is frustrating when you just want your site back online, but avoiding these specific pitfalls will make the recovery process much smoother.

1. Disabling the REST API via code: You might encounter snippets suggesting you add add_filter( 'rest_enabled', '__return_false' ); to your functions file. Avoid this entirely. While it might seem like a way to silence an error, it effectively shuts down the entire API infrastructure. Doing this will break core components of your site, specifically the Gutenberg block editor and several other native WordPress features. It’s a blunt instrument that causes more problems than it solves.

2. Persistent Caching: One of the most common reasons a fix doesn’t seem to “take” is a lingering cache. After you modify your .htaccess file or update your security settings, the server might still be serving the old, broken version of the page. You must manually purge your server-side cache (specifically Varnish or Nginx FastCGI Cache) and clear your plugin-level caching layers, such as WP Rocket. Until every layer is cleared, you’re looking at an old snapshot of the problem.

3. Ignoring 403 Errors: If your error logs show a 403 status, it’s vital to recognize what that actually means: “Forbidden.” This isn’t usually a bug within the WordPress core code; it is a signal that a gatekeeper—typically a firewall or an incorrectly configured .htaccess rule—is actively blocking the request. When you see this error, the solution lies in your server configuration and security layers, not in your WordPress plugins.

Comparison of Resolution Methods

Analysis Area	Action Required	Technical Difficulty	Business Impact
Permalinks	Save Settings in Dashboard	Low	Immediate fix for Gutenberg errors.
Security Plugins	Toggle “Allow REST” in settings	Medium	Ensures front-end features work.
.htaccess Edit	Manual code correction via FTP	High	Fixes structural routing issues.
ModSecurity	Contact Host Support	High	Resolves server-level blocks.

When to call a professional?

There are moments when a problem sits deeper in the server architecture than what you can resolve from your administrative dashboard. If you hit these specific roadblocks, it is time to hand off the keys to a specialist who can dig into the backend:

1. The “Save Permalinks” method fails to clear the error after multiple attempts. This usually indicates a deeper configuration conflict that standard WordPress settings can’t override.
2. You have verified your security plugins and confirmed all permissions are set to “Allow,” yet the issue persists. Some rules are buried too deep for a standard plugin toggle to fix.
3. Your server logs show persistent 403 Forbidden errors specifically on /wp-json/ paths that remain unresolved after you have manually edited your .htaccess file.
4. The site has gone dark, the editor is completely inaccessible, and you do not feel comfortable navigating your files via FTP to perform emergency repairs.

A professional can quickly determine if the block is being triggered at the server’s firewall level (such as ModSecurity) or if a specific conflict exists where two different plugins are fighting for the same hook within the WordPress core.