Skip to main content
web-design

The API Under the Floorboards: 286 Endpoints That Change WordPress Fleet Operations

Idea Forge Studios
The API Under the Floorboards: 286 Endpoints That Change WordPress Fleet Operations

Executive Summary

We have been building fleet operations tooling for several research cycles, and we recently discovered that the toolbox we have been trying to build already exists. It has been sitting in the platform we run on, undocumented in our workflow, for over a year.

For most of that time we designed systems from scratch: a vulnerability scanner, a security hardening must-use plugin, a fleet deployer, a database optimization strategy, a five-layer observability stack. Every one of them assumed SSH was our only programmatic interface to the fleet. Every one of them was designed around the constraint that we have to manually connect to individual servers to do anything.

That constraint was wrong. We found the Enhance Control Panel's REST API, a full OpenAPI 3.0.3 specification with 286 endpoints, version 12.21.3, published at apidocs.enhance.com/spec/oas3-api.yaml. It includes complete WordPress management: list, install, and delete plugins, update themes with version control, single sign-on into any WordPress admin panel, manage wp-config settings, toggle maintenance mode, manage cron jobs, all via authenticated REST calls. No SSH required.

The second discovery came from studying how WP Engine, Pantheon, and WordPress VIP handle fleet operations at scale. The industry pattern is Visual Regression Testing (VRT): take screenshots before an update, apply the update, take screenshots after, algorithmically compare them, auto-rollback if anything changed. WP Engine's Smart Plugin Manager does this with proprietary ML. Pantheon does it with BackstopJS (open-source). And the Enhance control panel API has a screenshot/take endpoint built in.

The convergence is almost too clean. The Enhance API gives us fleet-wide WordPress management without SSH. The VRT pattern gives us safe automated updates. The screenshot endpoint gives us before-and-after comparisons. Combined with the rest of the observability and database optimization work, we now have the architecture for a complete fleet management system that doesn't require building everything from scratch.

WordPress SRE at Scale: How the Professionals Run Fleets

Designing systems in isolation isn't engineering, it's blueprinting. We asked: how do the companies that actually manage thousands of WordPress sites do it? The answer reshaped our understanding of what "fleet management" means.

The Industry Standard: Visual Regression Testing

The biggest surprise wasn't a specific tool or technique, it was a workflow pattern that every major managed WordPress host has converged on independently. It's called Visual Regression Testing (VRT), and it solves the problem of "how do I know an update didn't break something?" with an elegance we didn't expect.

The professional VRT update workflow runs in five phases:

  1. Baseline. Take screenshots of homepage and key pages. Both desktop and mobile viewports. Record HTTP status codes. Create a backup or checkpoint.
  2. Update (one plugin at a time). Apply a single plugin update. Clear all caches (page, object, CDN, CSS). Wait for page generation.
  3. Verify. Take post-update screenshots of the same pages. Compare screenshots pixel-by-pixel. Check HTTP status codes (4xx/5xx fails). Check for PHP errors in response. Check for missing images, forms, icons.
  4. Decide. Visual change detected, auto-rollback. HTTP error, auto-rollback. PHP error, auto-rollback. All clean, proceed to next plugin.
  5. Report. List updated plugins with versions. List rolled-back plugins with reasons. Before-and-after screenshots for review. Notification to site admin.

This is the workflow that WP Engine, Pantheon, and every serious managed host uses. The details vary, but the pattern is universal.

WP Engine's Smart Plugin Manager: The Gold Standard

WP Engine's Smart Plugin Manager (SPM) is the most sophisticated implementation we found. Screenshot scope covers up to 10-20 pages per site (configurable), always includes the homepage, tests both desktop and mobile viewports, and on WooCommerce sites automatically includes cart, checkout, account, plus 3 random category pages and 13 random product pages. Multisite installations test homepages of up to 49 subsites.

Comparison methods include side-by-side, overlay, and slider views for human review. Rollback triggers include 4xx/5xx HTTP errors, "material change to the look of your site," missing images, forms, misplaced icons, and PHP errors in output.

Per-plugin isolation is the killer feature: "the system will attempt to update each plugin or theme individually and will skip updating the plugin or theme to the specific version that caused the failure while still updating the other components." One broken plugin update doesn't prevent the rest from being applied.

VRT sensitivity is adjustable. Dynamic content (calendars, ads, rotating banners) can be excluded via a "Hidden Content" feature to prevent false positives.

WP Engine acknowledges the key limitation honestly: "It's impossible to know exactly what percentage of changes VRT will catch." VRT is a safety net, not a guarantee. But a safety net that catches most visual regressions is infinitely better than no safety net.

Pantheon Autopilot: The Open-Source Approach

Pantheon achieves the same workflow using open-source tools.

Component Tool Purpose
Update engine WP-CLI Checks for and applies updates
VRT BackstopJS Screenshot comparison (open-source, self-hosted)
CI/CD CircleCI Daily scheduled runs
Deployment Terminus (Pantheon CLI) Environment management, merges
Notification Slack Status alerts
Version control Git Deployment history

CircleCI runs daily. WP-CLI checks for available updates. If found, updates are applied in an isolated Multidev environment, not production. BackstopJS takes screenshots and compares against the live site at 0% tolerance: any visual difference blocks deployment. If clean, changes are merged and deployed via Terminus.

The key insight: they don't test in production. They clone to a staging environment, test there, and only push to live if VRT passes. This is the clone plus push-live pattern that the Enhance control panel API supports natively.

WordPress VIP: The Enterprise Scale

WordPress VIP (Automattic's enterprise tier) operates at a different scale entirely. Everything containerized on Kubernetes, each customer isolated. CDN with 28 global data centers, Varnish edge caching. NGINX serving 70,000 requests per second, 15+ Gbps traffic. Automatic core and plugin rollouts across all data centers simultaneously. Hourly automated multi-region replicated backups. 24/7 fully managed monitoring.

This isn't replicable for our scale, but the principles apply: containerize, automate, replicate, monitor.

What This Means for Most Fleets

The professional pattern is clear:

  1. Never update in production without a safety net. Either use a staging environment or have instant rollback capability.
  2. Visual comparison is the universal verification method. Not logs. Not HTTP status codes alone. Actual screenshots compared pixel-by-pixel.
  3. Update one thing at a time. Per-plugin isolation means you know exactly which update caused a problem.
  4. Automate the boring parts. Checking for updates, applying them, taking screenshots, comparing: all automatable. Humans review the results, not the process.

We already have most of the pieces. Our Playwright-based audit tooling takes screenshots and captures console errors. The Enhance control panel API can list plugins, apply updates, take screenshots, create backups, and restore from backups. BackstopJS is free and open-source. The missing piece isn't technology, it's the workflow that connects them.

The Enhance CP API: The Toolbox Under the Floorboards

We had been building SSH-based tools for many research cycles. We discovered the hosting platform we use has a full REST API we never explored.

The Enhance Control Panel provides an OpenAPI 3.0.3 specification at https://apidocs.enhance.com/spec/oas3-api.yaml. Version 12.21.3 (updated April 14, 2026). Total endpoints: 286. Authentication: Bearer token (created at Settings > Access Tokens in the Enhance panel) plus Organization ID.

What the API Can Do

WordPress management without SSH: list installed plugins, delete plugins, get plugin versions, list installed themes, update a theme, configure auto-updates, list WordPress users, single sign-on into the WP admin, read and write wp-config, get site info, toggle maintenance mode, install WordPress.

Fleet operations: list every website in the fleet, clone a website to create a staging environment, push staging to production, take a screenshot, get last screenshot timestamp, manage cron jobs, manage SSH keys.

Backup and restore: list and create backups, download a backup, upload a backup, manage individual backups, check restore progress, browse backup contents.

Server infrastructure: disk usage, memory usage, CPU load, server uptime, network throughput, MySQL configuration (my.cnf), ModSecurity status, OWASP rule management, PHP-FPM status, per-site PHP-FPM, server role management.

SSL and security: issue Let's Encrypt certificates, manage SSL certificates, force HTTPS, per-domain ModSecurity.

What This Changes

Every system we designed over many sessions assumed SSH as the primary interface. The Enhance API removes that constraint for most operations.

For security hardening: instead of SSH plus must-use plugin deployment, we can check ModSecurity status and OWASP rules via API, and force SSL can be toggled via API per domain. REST API user enumeration and XML-RPC blocking still need a must-use plugin approach.

For fleet deployment: instead of custom SCP-based deployment scripts, the API can manage plugins and themes directly. Clone plus push-live is native to the API. Plugin installation and deletion is API-native. Custom must-use plugin deployment still needs SSH.

For database optimization: the my.cnf endpoint means we can read AND modify MySQL configuration via API. This was the missing piece: we couldn't tune innodb_buffer_pool_size without server access. Now we can.

For observability: server disk, memory, load, uptime, and network stats are all API endpoints. This replaces much of what we designed for the Grafana plus Prometheus layer. The API provides server-level metrics without deploying any monitoring agents.

The VRT Plus API Convergence

The fleet update pipeline we can now build looks like this:

Phase 1 (audit): list all sites, then for each site list all plugins, get plugin versions, and pull WordPress and PHP version info. Generate a fleet-wide plugin version matrix.

Phase 2 (stage, per site): create a pre-update backup, take a baseline screenshot, record HTTP status and response time.

Phase 3 (update, one plugin at a time): apply the update, wait for cache clear, take a post-update screenshot, compare screenshots (BackstopJS or our existing audit tooling), check HTTP status.

Phase 4 (decide): if VRT passes and HTTP returns 200, continue. If VRT fails or there's an HTTP error, enable maintenance mode, restore from backup, monitor restore status, alert. If all plugins updated, generate report.

Phase 5 (observe): check disk usage, memory usage, CPU load impact via API. External monitoring continues independently.

This is the complete fleet update pipeline. It uses the Enhance control panel API for all WordPress operations, BackstopJS or our internal audit tooling for visual regression testing, the API again for backup and restore, and the API a third time for server monitoring.

The only piece that still requires SSH is must-use plugin deployment. Everything else is API-native.

Known Limitations of the API Approach

From the Managing WP analysis and community discussions, the Enhance API has these constraints:

  1. No must-use plugin management. The API manages WordPress plugins (/wp-content/plugins/), not must-use plugins (/wp-content/mu-plugins/). Security hardening must-use plugins and custom client must-use plugins still need SSH deployment.
  2. No native WAF or XML-RPC control. The API manages ModSecurity at the server level but doesn't provide WordPress-specific protections like XML-RPC blocking or REST API user enumeration prevention.
  3. Backup frequency not configurable via API. The backup schedule is set at the platform level. On-demand backups are API-accessible but the automatic schedule isn't granularly configurable.
  4. No error log rotation. Enhance doesn't rotate error logs automatically. Disk space monitoring becomes the early warning system.
  5. Plugin version updates need verification. We found endpoints to get plugin versions and delete plugins. The theme update endpoint exists explicitly. The equivalent for plugins (update to a specific version, versus delete-and-reinstall) needs confirmation.
  6. S3 backup quirk. S3-targeted backups create a local backup first, then push to S3. This can exhaust disk space on servers with large databases.

What Unlocks This

A single credential: an Enhance control panel API access token, created in the panel at Settings > Access Tokens. With that token plus the Organization ID, programmatic management of the entire fleet becomes possible: WordPress plugin and theme audits and updates without SSH, backup and restore automation, server health monitoring, screenshot capability for visual regression testing, MySQL configuration management, ModSecurity and OWASP rule management.

Without it, every system we designed over many cycles remains manual. Fleet audits continue to require per-site SSH connections. Updates continue to require per-site WP-CLI commands. There's no automated rollback capability. There's no visual regression testing pipeline.

The Bigger Lesson

We had spent a lot of time designing things. A vulnerability scanner. A security hardening must-use plugin. A fleet deployer architecture. A database optimization strategy. A five-layer observability stack. Each one was designed around a fundamental assumption: that SSH is our only programmatic interface to the fleet.

That assumption was wrong. Not because SSH doesn't work (it does, and it remains necessary for certain operations), but because we never asked the question: what does the platform itself provide?

This is a pattern worth recognizing in software engineering generally. When you're building on a platform, you should understand the platform before building abstractions on top of it. We jumped to building because building felt productive. We designed systems because designing systems felt like progress. But we never sat down and read the API documentation for the infrastructure we actually run on. If we had done this at the start, everything afterward would have been different. More targeted. More practical. Less SSH-scripting-from-scratch and more "call the API endpoint that already exists."

The designs we built aren't wasted. They're refined by this new knowledge. The observability stack still needs external HTTP monitoring and Server-Timing instrumentation, but the server-metrics layer is largely replaced by the API's monitoring endpoints. The fleet deployer architecture is sound, but the implementation can use API calls instead of SSH for most operations. The database optimization plan now has a concrete path that doesn't require root SSH access.

The VRT research was the second revelation. We had been thinking about deployment safety as binary: it either works or it doesn't. The industry thinks about it as a spectrum of confidence: screenshots, HTTP status checks, visual comparison, console error detection, performance metrics. Each layer adds confidence. No single layer provides certainty. But the stack (backup, screenshot, update, screenshot, compare, decide) reduces risk to the point where automated fleet-wide updates become practical.

The convergence is what matters. Playwright-based screenshots and console errors. The Enhance API for screenshots, backups, and WordPress management. BackstopJS for open-source VRT comparison. External monitoring and Server-Timing instrumentation. These aren't separate tools. They're components of a single pipeline that we can now see clearly for the first time.

Sources

WordPress 7.0 Status

Fleet SRE Patterns

Enhance Control Panel API

Related Articles

The Phantom State Pattern: A Taxonomy of WordPress Context-Dependent Bugs

The Phantom State Pattern: A Taxonomy of WordPress Context-Dependent Bugs

A WP-CLI rescue that should have been two lines burned thirty minutes on a property that was NULL in CLI but populated in web requests. Here is the bug class behind that failure, and the self-healing pattern that prevents the next one.

 The Storefront Layer: Why GPT-5.4 Cites Pricing Pages 35x More Than the Old Default

The Storefront Layer: Why GPT-5.4 Cites Pricing Pages 35x More Than the Old Default

GPT-5.4 reads pricing pages as a primary information source. GPT-5.3 ignored them almost entirely. The default model just changed and we are inside a roughly seven-week corridor in which the citation surface is being rewritten.

 Entity Ghosting: When a Competitor Owns Your Name in AI Memory

Entity Ghosting: When a Competitor Owns Your Name in AI Memory

I ran the Ghost Citation Audit on our own company. Found something worse than ghost citation: AI parametric memory has handed our name to a different agency in another city. We are functionally invisible under our own brand.