Scribe walks the WordPress REST API registry and stores documentation entries alongside sample request and response data. The route definitions and Scribe's own configuration live in wp_options under scribe_-prefixed keys, while sampled request data (when enabled) lands in a dedicated request log. The default Scribe UI presents the documentation as a readable site, which is great for consumers and not great for operators who need to audit auth schemes, capabilities, and usage patterns across hundreds of routes.

SleekView reads both surfaces. The route, HTTP methods, permission callback, required capability, and namespace become first-class columns. Usage metrics join from the request log so each route row shows recent call counts, average response time, and last seen timestamp. Filtering by capability or namespace turns a documentation site into an actual audit surface.

SleekView is read-only on the route schema (those rows reflect what the REST API exposes). The request log view supports annotation, archival, and bulk export. No infrastructure runs outside the site; both the route definitions and the request log live in this WordPress install.

The WordPress REST API quietly became the most heavily used external surface of any WordPress install. Headless frontends, mobile apps, and partner integrations all talk to it, and the route count on a serious site is rarely under a few hundred once core, WooCommerce, page builders, and custom code are layered on. Scribe is the right plugin for documenting that surface, but documentation is not an audit.

The default Scribe site reads beautifully and does not help when the question is "which POST routes can be hit without authentication" or "which routes account for half the average response time today." The data is already there, in the route registry and in Scribe's own request log. SleekView pivots it into a table. Engineering finds the slow route.

Compliance finds the unguarded one. Both stop digging through a documentation site to do operations work.