Let your content team refresh live pages without a Cloudflare login

Build me a publish and purge desk: an internal app that lets our content and marketing team clear the cached version of pages they just updated, without giving any of them a Cloudflare dashboard login. The audience is non-technical, so every piece of copy in the app should talk about pages, posts and images rather than edge caches, zones or CDNs. Refreshing individual page addresses is the default and safest path, so make that the prominent action everywhere.

The main view is a list of recently published and updated posts, loaded from WordPress with List Posts filtered by status and modified date. Default to published posts modified in the last 14 days, newest first, with a control to widen the window and a search box. Each row shows the post title, the author, how long ago it was modified, and the live URL, with a checkbox on the left. Use the author information embedded in the posts response where it is available and fall back to the author id when it is not. A Refresh selected pages button takes the checked rows and clears exactly those URLs using Purge Cache by URL. Note that our catalog only exposes posts for WordPress, so scope this panel to posts and let the manual panel below cover images, landing pages and anything else.

A second panel accepts addresses pasted by hand, one per line, and also accepts a bare hostname or a path prefix for people who want to clear a whole section. For hostname and prefix requests, use Purge Cache by Tag, Host, or Prefix. That operation is Enterprise-only on Cloudflare, so if the plan rejects it do not surface a raw error. Fall back to expanding the request into individual address purges through Purge Cache by URL where you can, and say plainly that clearing a whole section is not available on this plan and that they should paste specific page addresses instead.

The app has to work out which Cloudflare zone each address belongs to so that nobody using it has to know what a zone is. On load, call List Zones to get the zones the API token can see, then match each address hostname against the zone names, with the longest matching suffix winning. When a hostname does not map to a zone name directly, for example a subdomain or a vanity host, call List DNS Records for the candidate zones and match against the record names. Hold the resolved mapping in app state for the session so you are not re-resolving on every purge. If an address cannot be matched to any zone, leave it out of the batch and list it under a short heading such as: we could not match these addresses to a site you have access to.

Refreshing an entire site sits behind a guarded confirm and uses Purge All Cache. The dialog makes the person choose the site, type a reason into a free text field, with the confirm button staying disabled until that reason is filled in, and read a warning that explains in plain terms that clearing everything means every page has to be rebuilt from our own server for a while, which can slow the site down for visitors, so it should only be used after a site wide or theme level change. Visually de-emphasize this action and mark it as a last resort. Store the typed reason on the history record.

Every purge, successful or not, writes a row to a history table stored in the app's own database: who ran it, when, the type of refresh (selected posts, pasted addresses, hostname or prefix, or everything), the addresses or target involved, the site name, the typed reason where there is one, and whether Cloudflare accepted it including the failure reason when it did not. The history view is filterable by person and by date range and shows newest first. This is the record engineering will look at when someone asks why a page changed.

After each purge, post one short line to a web ops Slack channel using the Slack Bot Send a Message operation, for example: Jess refreshed 3 pages on example.com, accepted by Cloudflare. Keep it to a single line covering who did it, how many pages, which site, and the outcome. Let the channel be set in a small settings area. If the Slack post fails, still record the purge in history and do not block the person using the app.

Handle Cloudflare's limits properly rather than leaking errors. Cloudflare caps how many addresses one purge request can carry and how many requests a token can make in a window, so send addresses in batches of up to 30 per request, run the batches one after another, and if Cloudflare returns a rate limit response, pause and retry the remaining batches instead of failing the whole run. Never show a raw API error. Show progress in plain language, such as: Cloudflare is busy right now, we have refreshed 12 of 30 pages and are still going. Finish with a plain summary of how many pages were refreshed and how many did not go through, with a retry option for the failures.