Run wp dbtk api discover to scan every REST route registered on your WordPress site by core, plugins, and themes, and save the results to WP Debug Toolkit’s (WPDT) schema store. Then run wp dbtk api list to view results in a formatted table or JSON, with optional filtering by namespace, source slug, or HTTP method. A typical site returns hundreds of routes across more than a dozen sources.
Running wp dbtk api discover once gives you a complete map of every active REST route on your site, recording the namespace and registering codebase for each one. The wp dbtk api list command reads from that schema store and lets you display and filter the results.
discover is the prerequisite step. Without it, wp dbtk api list returns only WPDT’s own endpoints. After running discover, use list to scope and inspect the full route set. Searching and Filtering Routes covers the complete set of list filtering options.
bash
# Scan all registered REST routes and save to the schema store.
# This command takes no flags — it is a one-pass scan.
wp dbtk api discover
# View discovered routes as a formatted table (default output format)
wp dbtk api list
# Filter by REST namespace — pass the namespace string, e.g. wp/v2 or wc/v3
wp dbtk api list --namespace=wp/v2
# Filter by source slug — pass the value shown in the Source column
wp dbtk api list --source=wordpress-core
# Filter by HTTP method (case-insensitive)
wp dbtk api list --method=GET
# Show only routes that have annotations attached
wp dbtk api list --annotated-only
# Filter by annotation tag
wp dbtk api list --tag=products
# Return full JSON output for programmatic use or piping to jq
wp dbtk api list --format=json
# Combine filters — WooCommerce POST routes only
wp dbtk api list --namespace=wc/v3 --method=POSTwp dbtk api list writes four columns for each route. Use these values when building filters or passing a route to wp dbtk api show.
| Attribute | Value Type | Notes |
| Source | String | The source slug derived from the route’s REST namespace. WordPress core routes appear as wordpress-core. WPDT’s own routes appear as wpdebugtoolkit. For other plugins, WPDT strips the version from the namespace and sanitizes the result. For example, WooCommerce routes registered under wc/v3 appear as wc, Jetpack routes under jetpack/v4 appear as jetpack. Pass this value to --source to scope wp dbtk api list to a single codebase. |
| Route | String | The full route path including namespace prefix. Examples: /wp/v2/posts, /wc/v3/products. Pass this value to wp dbtk api show to inspect the full schema for that route. |
| Methods | String | Comma-separated HTTP methods the route supports. Examples: GET, GET, POST. |
| Description | String | A human-readable summary where the registering code provides one. Populated from the summary field, falling back to description. Returns an empty string where neither field is set by the registering code. |
Namespace Filtering
Each source in the schema store carries the namespace recorded at discovery time. When you pass --namespace to wp dbtk api list, WPDT matches the value as an exact string against the stored namespace for each source and returns only that source’s routes.
The namespace string and the source slug are two different values: --namespace=wc/v3 matches WooCommerce routes by namespace, while --source=wc matches them by source slug. Both produce the same result for WooCommerce, but the syntax is not interchangeable.
bash
# Filter by namespace string — must be an exact match
wp dbtk api list --namespace=wp/v2 # WordPress core routes
wp dbtk api list --namespace=wc/v3 # WooCommerce routes
# Filter by source slug — the value shown in the Source column
wp dbtk api list --source=wordpress-core
wp dbtk api list --source=wc
# Combine filters to narrow further
wp dbtk api list --namespace=wc/v3 --method=POST --format=jsonwp dbtk api list results by namespace?Pass --namespace=<value> with the exact namespace string, for example, wp/v2 or wc/v3. Namespace is not a column in the wp dbtk api list output, but you can read it from the Route column: a route like /wc/v3/products tells you the namespace is wc/v3. You can also filter by source slug using --source=<slug>, which takes the value shown in the Source column rather than the namespace string.
No. The wp dbtk api list table does not include an authentication column. WPDT stores authentication data from route registrations in the schema, but exposes it through wp dbtk api show <route>, which displays an Auth row showing the route’s permission callback. Discovered third-party and core routes carry the permission_callback value recorded at discovery time. Routes annotated with wp dbtk api edit may also carry an auth note. See Inspecting an Endpoint for the full schema reference.
Searching and Filtering Routes – Got hundreds of routes back on an unfamiliar codebase? Use this to filter by namespace, method, or keyword and find the one you actually need.
Inspecting an Endpoint – Take any route from the list above and pull its full schema: parameters, types, validation rules, and authentication requirements.
Annotating Routes with Custom Metadata – Attach descriptions, safety labels, and auth notes to discovered routes so your team and your AI coding tools know what each one does.
