Note the action that failed, the request URL and method, and the HTTP status. Inspect the response body for a WordPress error code, a login page, a firewall challenge or a server error. Remove authentication headers, cookies and private payload data before sharing any network capture.

A public API route working does not prove an authenticated write route works. Test the specific operation involved using a safe draft or non-destructive request where possible.

1. Confirm that the site URL and HTTPS configuration are correct and that the request is not redirected to another hostname.
2. For an editor request, check whether the login session or request nonce expired.
3. For an external integration, verify its supported credentials and the associated user's capabilities.
4. Review security-plugin, web-application-firewall and server logs for a matching blocked request.
5. Check PHP logs when the endpoint returns a server error or non-JSON output.

Use this unauthenticated GET only to check the public posts route on the intended site. It asks for one item and selected non-sensitive fields. Sites with an intentional policy restricting public REST access may reject it by design.

curl --silent --show-error --include \
  --connect-timeout 3 --max-time 15 --get \
  --data-urlencode 'per_page=1' \
  --data-urlencode '_fields=id,link' \
  'https://example.com/wp-json/wp/v2/posts'

A JSON list, including an empty list on a site with no public posts, is different from an HTML login or firewall page. Record the actual status and content type. This test does not validate the authentication, nonce or capability required for an editor save or a plugin-specific endpoint.

Expected result: The public route behaves according to the site’s policy. The original failing authenticated operation is investigated and tested separately, without disabling the whole firewall or exposing private API routes to make this diagnostic pass.

An authentication or permission error requires the correct user and capability, not a blanket public-access exception. A not-found response can indicate an incorrect route, missing plugin endpoint or rewrite issue. A rate-limit response needs a review of request volume and retry behaviour.

If a firewall rule causes a false positive, provide the precise request and rule evidence so a narrow correction can be considered. Disabling the firewall for the entire site creates a much broader change than necessary.

Repeat the intended request and confirm both the status and expected result. For a write operation, check the saved data in a separate view. For an integration, verify that it does not accidentally duplicate an action after a timeout.

Review the public and authenticated boundaries after any configuration change. A working editor should not require exposing private endpoints to unauthenticated visitors.

Include the domain, endpoint path, method, time, status and sanitised error response. State whether the request originates from the browser, the server itself or an external application. Those paths can encounter different DNS, proxy and authentication conditions.

Do not send a full browser session export containing cookies. If a plugin adds the failing endpoint, include its version and recent changes. Keep the investigation scoped to the required route and restore any temporary diagnostic changes after verification.

• Resolving the editor's invalid JSON response error
• Creating and revoking WordPress application passwords
• Troubleshooting failed loopback requests
• Checking WordPress core file integrity with WP-CLI

• REST API authentication
• REST API reference
• WordPress documentation

• WordPress REST API posts
• curl command options