wp dbtk api show <route> returns the registered schema for a single REST endpoint, including parameter names, types, required status, and authentication requirement, without making a live request. Add --method=GET to narrow output to one HTTP method’s parameter set, or --format=json to retrieve the raw schema object.
Schema inspection gives you exactly what an endpoint expects before you write client code, build an agent prompt, or send a test request. Where wp dbtk api discover and wp dbtk api list map the full inventory of registered routes, wp dbtk api show goes deep on one route. WP Debug Toolkit’s (WPDT) own routes are available immediately without any prior discovery step. For WordPress core and third-party plugin routes, run Discovering Registered Routes first to populate the schema store; show reads from that stored data, not from a live server request.
bash
# Show the full schema for a specific route
wp dbtk api show /wp/v2/posts
# Narrow output to one HTTP method's parameter set
# GET and POST on the same route often accept different parameters
wp dbtk api show /wp/v2/posts --method=GET
# Return the full endpoint object as JSON for programmatic use
wp dbtk api show /wp/v2/posts --format=jsonwp dbtk api show outputs a two-column table (Field / Value) by default. The fields below describe each row that appears in that output.
| Field | What It Shows | Example Value |
|---|---|---|
| Route | The full registered route path | /wp/v2/posts |
| Methods | Supported HTTP methods, comma-separated | GET, POST |
| Summary | Human-readable endpoint description, when present | Retrieves a collection of posts |
| Safety | Safety classification set via annotation | read-only |
| Verification | Annotation verification state | verified-source |
| Auth | The authentication requirement for this route. Discovered routes show the stringified permission callback name. WPDT native and annotated routes show a semantic label. Falls back to unknown if none is recorded | is_user_logged_in (discovered), admin (native) |
| Parameters | Header row marking the start of per-parameter entries | |
| (param name) | Each parameter rendered as name (type), with [required] appended only for mandatory parameters and – description appended only when a description is present | status (string) - Limit result set by status or id (integer) [required] |
| Method Annotations | Header row for per-method annotation summaries, when present |
The table display compresses each parameter into a single line. Use --format=json to access the full sub-field structure for each parameter.
| Sub-Field | What It Shows | Example Value |
|---|---|---|
| type | Accepted data type for this parameter | string |
| required | Whether the parameter must be present in the request | false |
| default | Value used when the parameter is omitted. Always present in discovered-route output, emitted as null when no default is declared. Present in native route output only when the schema explicitly sets one | publish |
| description | Human-readable explanation of what the parameter controls | Limit result set to posts assigned a specific status |
| enum | Allowed values when the parameter is constrained to a fixed set; present only when applicable | ["publish", "draft", "pending", "private", "trash"] |
json
// wp dbtk api show /wp/v2/posts --format=json (trimmed — discovered route)
{
"route": "/wp/v2/posts", // full registered route path
"methods": ["GET", "POST"], // supported HTTP methods
"params": {
"status": { // parameter name as used in the request
"type": "string", // accepted data type
"required": false, // true for mandatory parameters
"default": "publish", // always present; null when no default is declared
"description": "Limit result set to posts assigned a specific status",
"enum": ["publish", "draft", "pending", "private", "trash"]
// enum present only when values are constrained
}
// additional parameters follow the same structure
},
"permission_callback": "is_user_logged_in",
// auth for discovered routes; shown as Auth in table mode
"handlers": {
"GET": { // per-method handler detail
"permission_callback": "is_user_logged_in",
"params": { } // method-specific params (trimmed)
},
"POST": {
"permission_callback": "is_user_logged_in",
"params": { } // method-specific params (trimmed)
}
} // handlers key present for discovered routes only
}WPDT native routes produce a structurally different JSON object: auth replaces permission_callback, description replaces summary, params is often empty, and the handlers key is absent.
wp dbtk api show and wp dbtk api call --profile?wp dbtk api show reads the registered schema without making a request. It tells you what an endpoint expects: parameter names, types, required fields, and auth requirements. wp dbtk api call --profile makes a live internal dispatch and measures execution time, memory usage, and query performance. Use show to understand what an endpoint accepts before writing code; use call --profile to measure how it performs under real conditions.
wp dbtk api show require me to be authenticated as a specific user to see auth-gated schema details?No. wp dbtk api show reads from the stored schema: JSON files written to disk during discovery or from the WPDT static schema. That data is read at the file level, not by issuing a live REST request, so your current authentication state has no effect on the command’s output. The Auth row shows the authentication requirement for the route; a stringified permission callback name for discovered routes, or a semantic label such as admin for WPDT native and annotated routes. It describes what authentication the endpoint requires, not whether your current session would pass it. To test actual access, use wp dbtk api call under the appropriate user context.
Discovering Registered Routes – Map all registered routes first; schema inspection targets a single route from that inventory.
Profiling Endpoint Performance – Once you know what an endpoint accepts, use profiling to measure how it performs under real conditions.
Annotating Routes with Custom Metadata – Attach persistent notes, safety classifications, and auth descriptions to routes you’ve inspected. This is useful for teams and AI agents working with the same API.
