Block Endpoints with Custom Response

Disable any WordPress REST API endpoint with a single toggle and control exactly what blocked clients receive. Choose a custom HTTP status code and response message so blocked requests return a response that fits your security policy — whether that’s a 403 Forbidden, 404 Not Found, or a custom error.

What It Does

Every registered REST API endpoint on your site appears in the Endpoint Manager interface, organized by namespace in a collapsible accordion. Toggle any endpoint off to block all requests to that route. When an endpoint is blocked, the plugin intercepts the request before WordPress processes it and returns your configured HTTP status code and message.

Each namespace shows a badge counting how many of its endpoints are currently disabled, giving you an at-a-glance view of your API lockdown status. A confirmation dialog prevents accidental changes when you block new endpoints.

Key Capabilities

• Toggle any REST API endpoint on or off with a single click
• Configurable HTTP response code for blocked requests (403, 404, etc.)
• Custom response message returned to blocked clients
• Disabled endpoint count badge per namespace
• Confirmation dialog before saving changes to prevent accidental blocks
• Works with all endpoint types — WordPress core, plugin, and theme routes
• Blocked requests are logged in the security logs with IP, user agent, and timestamp

How to Use It

Navigate to Endpoint Manager → Endpoints to see all registered routes grouped by namespace. Expand any namespace to see its endpoints, then toggle off the ones you want to block. Configure your preferred response code and message in the settings. Save your changes — a confirmation dialog will summarize what you’re about to block before applying.

Use the namespace badge counts to quickly audit how many endpoints are disabled across your site. Combine with dynamic endpoint support to manage both static and parameterized routes from the same interface.

Why It Matters

WordPress exposes dozens of REST API endpoints by default, and every plugin you install adds more. Many of these endpoints are never used by your site but remain publicly accessible — leaking information about your WordPress version, installed plugins, user accounts, and content structure.

Blocking unused endpoints reduces your attack surface. Returning a custom response code lets you control the information you reveal — a 404 tells scanners the route doesn’t exist, while a 403 confirms it exists but denies access. Choosing the right response is part of a deliberate security strategy.

Frequently Asked Questions

Will blocking an endpoint break my site?

It depends on the endpoint. WordPress core and some plugins rely on specific REST API routes for admin functionality (e.g., the block editor uses /wp/v2/posts). The confirmation dialog helps you review changes before applying them. If something breaks, re-enable the endpoint to restore functionality immediately.

What’s the difference between returning 403 and 404?

A 403 (Forbidden) tells the client the endpoint exists but access is denied. A 404 (Not Found) tells the client the endpoint doesn’t exist. Use 404 if you want to hide the existence of the route from scanners; use 403 if you want to be transparent that access is restricted.

Can I block all endpoints in a namespace at once?

You can toggle endpoints individually within each namespace. The namespace accordion and disabled count badge make it easy to work through endpoints systematically.