Skip to main content
Lightify registers its endpoints under the lightify/v1 namespace. They serve the admin screen, the admin bar, and the front-end vitals collector, so treat them as an internal API rather than a versioned public contract.
The purge endpoints are the exception worth knowing about, because they are genuinely useful from a deploy script.

​
Endpoints

​
Cache

​
Purging

Four endpoints, matching the admin bar menu.
​
endpoint
Clears the cached copy of one page.
​
endpoint
Clears the page cache and warms it again. Leaves optimized assets in place.
​
endpoint
Clears the cache and preloads.
​
endpoint
Clears everything, including optimized CSS, JavaScript, and images, then preloads. Use after changing optimization settings, since assets generated under the old settings are otherwise kept.
Each fires the matching purge actions, so integrations propagate to Cloudflare, Varnish, and your host at the same time.
Calling purge-everything-and-preload at the end of a deploy is the cleanest way to avoid serving stale pages after a release. Preloading immediately afterwards means your first real visitor still gets a cached page.

​
Other cache routes

​
endpoint
Starts preloading without purging first. Fills gaps rather than rebuilding.
​
endpoint
Reports whether page caching is actually active, returning active, wpconfig, or dropin. See confirming page caching.
​
endpoint
Rebuilds the service worker from current settings. Use after changing the lightify_serviceworker filter.

​
Settings

​
endpoint
Merges the supplied values over the stored settings. Send only the keys you want to change.
Fires lightify_settings_update:before and :after.
Changing an optimization setting does not rebuild existing cached pages. Follow a settings change with a purge, or visitors keep getting pages built under the old configuration.
There is no GET counterpart. Read settings in PHP with get_option('lightify_settings').

​
Metrics

​
endpoint
Returns the performance score and the Core Web Vitals behind it.
​
endpoint
Public. Receives measurements from the collector script in visitors’ browsers.This is the only public endpoint in the plugin, because the browsers reporting are anonymous. It is defended inside the handler rather than by a capability check: a token, an origin check, a per-IP rate limit, bounds on accepted values, and median aggregation over a ring buffer, so a flood of fabricated beacons cannot move the number much.
​
endpoint
Pro. Returns the specific recommendations shown on the overview page. Only registered with an active license.
​
endpoint
Which pages have been cached and optimized.
​
endpoint
Which CSS, JavaScript, image, and font files have been processed.

​
Authentication

Every endpoint except /web-vitals/report requires manage_options and a valid X-WP-Nonce header. For a purge from a deploy script running outside a browser session, use an application password:
The application password’s user needs manage_options, which is administrator-level access. Create a dedicated user for it rather than reusing your own account, and revoke the password when the pipeline changes hands.