Checked for accuracy and updated on September 21, 2026.
If you’ve landed here, one of two things is true. Either something on your site broke and the cause turned out to be the REST API, or you’re deliberately trying to turn it off and want to do it without breaking anything else. The fix is different depending on which one you are, so start by figuring out which situation you’re actually in.
How to check if the REST API is actually disabled
Visit yoursite.com/wp-json/ directly in a browser. A working REST API returns a block of JSON describing your site’s routes and namespaces. If you get a 404, a 403, or a blank white screen instead, something is blocking it. Try yoursite.com/wp-json/wp/v2/posts too. A 401 there specifically means authentication is being enforced, which is a narrower and usually intentional restriction, not a full disable.
This distinction matters because “disabled” covers a range of behavior. A full block returns a 404 for every route. An authentication requirement returns a 401 only for requests that aren’t logged in. Confusing the two leads to overcorrecting, either forcing the whole API back open when only login-gating was needed, or trying to gate logins on a site where the API is actually just broken.
If it broke and you didn’t do it
The REST API doesn’t disable itself, so something changed. Work through these in order, since they’re ranked by how often they’re actually the cause:
Security plugins. Wordfence, Solid Security (formerly iThemes Security), NinjaFirewall, and Shield Security all ship a “disable REST API” or “restrict REST API” toggle, and it’s easy to enable during a hardening pass and forget about. Check each active security plugin’s settings for anything mentioning “REST API,” “JSON API,” or “XML-RPC” (a different feature, but often toggled in the same settings panel and easy to confuse).
A leftover code snippet. Older WordPress security tutorials (many predating the block editor, which depends on the REST API) recommend adding a snippet like this to functions.php or a custom plugin:
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
if ( ! is_user_logged_in() ) {
return new WP_Error( 'rest_disabled', 'REST API restricted', array( 'status' => rest_authorization_required_code() ) );
}
return $result;
} );
This particular snippet only blocks unauthenticated access, which is usually fine. A more aggressive version removes the rest_api_init action entirely, which blocks everything, including the block editor itself. Search your theme’s functions.php and any custom or “site-specific” plugin for rest_authentication_errors or rest_api_init to find it.
Host-level firewall rules. Some managed hosts and CDN-level web application firewalls block /wp-json/ by default as a security baseline, independent of anything in WordPress itself. If neither a plugin nor your code is the cause, this is next; your host’s support team can confirm in a few minutes.
If you’re disabling it on purpose
Full REST API removal is rarely the right move on a modern WordPress site, and the reason is specific: since WordPress 5.0, the block editor (Gutenberg) reads and writes post content through the REST API. Disable the API outright and the editor stops saving, autosaves stop working, and the post list screen can throw errors. Jetpack, most page builders’ front-end editors, and any mobile app connection to your site rely on it too.
What you’re usually actually trying to prevent is unauthenticated access, not the API’s existence. The rest_authentication_errors filter shown above does that: logged-in users and legitimate admin-side requests keep working, while anonymous requests to your data get rejected. That closes the real risk, information disclosure to anyone who requests /wp-json/wp/v2/users and enumerates your usernames, without touching anything the editor needs.
If a specific integration needs authenticated API access from outside the browser (a mobile app, a headless front end, a Zapier-style automation), use WordPress’s built-in application passwords (Users → Profile → Application Passwords) rather than reopening the whole API to anonymous requests. It scopes access to one user account and can be revoked individually without touching the REST API’s global availability.
The one thing not to disable
Regardless of which security plugin’s settings page you’re in, leave the core wp/v2 namespace itself alone and restrict access with a filter instead of a route removal. Removing the namespace entirely rather than gating it is what breaks the editor, since the editor can’t distinguish “intentionally restricted” from “not there.” A 401 is something the admin dashboard already knows how to handle gracefully; a missing route generally isn’t.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.