Skip to content
HeadlessWP Pro

Admin console

Logs, security signals, and self-tests for operating headless WordPress.

Admin console guide

The Admin console is the operator surface for HeadlessWP Pro. Use it to configure policy, narrow API exposure, and diagnose production issues.

Where to find it

In WordPress admin, open HeadlessWP Pro and use the tabbed Admin console.

Key sections

Logs

Use logs to inspect /headlesswp/v1 request activity. For each incident, capture:

  • timestamp
  • route and method
  • status
  • correlation id (X-Correlation-Id and/or response meta.correlationId)

Security Events

Review security-relevant signals such as:

  • rate limit hits
  • suspicious request flags
  • authentication failures

This is the quickest way to separate misconfiguration from malicious traffic patterns.

Self Test & Environment

Run self-tests when a feature "should work" but does not. This verifies plugin wiring and dependency readiness.

Use environment export/import to compare and replicate configuration across local, staging, and production.

Endpoints and Service Accounts

Use these together to reduce attack surface:

  • disable endpoints you do not use
  • set endpoint access mode appropriately (Any vs API key only)
  • create least-privilege service account keys

Settings (rate limiting and suspicious requests)

Use Settings to define global defensive policy, including request limits and suspicious request handling mode (log, throttle, block).

When to use this vs your app logs

Use the Admin console first when you need plugin-level truth (policy denials, route gating, auth mode failures, rate limiting, suspicious request decisions).

Use your app logs for UI/business flow context (user actions, page state transitions, internal retries). For fastest triage, correlate both sides by correlation id.

What to capture for support

Provide the following in every support ticket:

  • site URL and environment (local/staging/production)
  • endpoint + method
  • HTTP status
  • correlation id
  • auth mode used (cookie, bearer, or API key)
  • sanitized request headers/body (no secrets)
  • Self Test export when issue appears environment-specific