Astro ISR Purge

A statically-generated Astro storefront is fast because it caches — which means a content edit in Magento doesn’t show up until something invalidates that cache. Astro ISR Purge closes that gap: the moment you save a product, category, CMS block/page or a global setting, it fires a tagged purge webhook to your storefront and names exactly which prebuilt HTML to delete, so the change is live in seconds without a full rebuild.

Your storefront needs a webhook receiver

This module sends the purge — your Astro storefront must have a matching webhook endpoint that receives the { tags, prebuildKeys } payload (with the shared Bearer secret) and clears the named CDN tags / prebuilt HTML. Without that receiver deployed on Netlify/Cloudflare, the purge fires into the void and nothing invalidates. Set the endpoint URL and secret in this module’s config (below).

Compatibility

Magento

Open Source 2.4.9 GA (and later 2.4.x).

PHP

Tested on 8.4 and 8.5.

Targets

Netlify, Cloudflare, or any Astro endpoint (provider-neutral webhook).

Safety

Fire-and-forget — a failing purge never blocks an admin save.

What triggers a purge

It observes save/delete across the catalogue and content and maps each to cache tags:

Edit	Tags
Product (or its stock / MSI source item)	mg-p-{id}, mg-p-{sku}
Category	mg-c-{id} (+ mg-global if in the nav tree)
CMS page	mg-cms-p-{identifier} (+ Redis dual-purge)
CMS block	mg-cms-b-{identifier} (+ Redis dual-purge)
Store / website / design & global config	mg-global
Catalog price rule applied	mg-products-all
URL rewrites	mg-url-rewrites

Prebuild self-heal

A tag purge clears the CDN edge, but a prerendered HTML blob can still be served until the next deploy. So for product / category / CMS edits this module also sends the exact prebuilt-HTML keys ({pageType, slug}) to delete — the self-healing piece that makes a content edit show up without a rebuild.

How it works

1. You save content in Magento. An observer resolves the change into cache tags (and, where relevant, prebuilt-HTML keys).

2. It POSTs a Bearer-authenticated JSON webhook ({ tags, prebuildKeys }) to every enabled store view’s configured storefront URL — with a 2-second hard timeout.

3. Your Astro storefront receives it and runs the provider-specific purge (Netlify purgeCache, Cloudflare cache-tag API, …) and drops the named prebuilt blobs.

4. CMS and global changes also publish on a Redis channel, so a storefront keeping an in-memory bundle snapshot refreshes it immediately.

It never blocks a save

The webhook has a 2-second timeout and all errors are caught and logged, never thrown — so a slow or down storefront endpoint can never stop a merchant from saving content. Worst case, the edit simply isn’t purged and refreshes on its natural TTL.

Configuration

Stores → Configuration → AgenticEcom · Headless & Astro → Astro ISR

Group	Key settings
General	Enable (per store view), Webhook URL(s) (comma-separated for dual-publish), Webhook Secret (encrypted, sent as Bearer), debug logging.
Redis	Host, port, channel for the dual-purge of bundle snapshots.

Per-store, multi-target

Webhook URL and secret are store-view scoped, so each storefront (or brand) has its own endpoint. List several URLs to dual-publish — useful during a platform migration (Netlify → Cloudflare) or multi-region deploy.

Manual / CI purge

There’s also a REST endpoint for emergency or CI/CD purges:

POST /V1/agenticecom/purge      (Admin Bearer token)
{ "tags": ["mg-p-123", "mg-cms-b-footer"] }

It runs the same Netlify + Redis purge path as the observers, and is gated by admin authentication.

Extending it

Other modules can register an ISR tag contributor to map their own entity events to cache tags without editing the core observer — so a new content type can invalidate the edge cache by adding a small contributor and binding its event. (AgenticEcom’s URL-rewrite module uses exactly this to fire mg-url-rewrites.)

FAQ

Do I have to rebuild the storefront after every edit?

No — that’s the whole point. A tagged purge plus the prebuilt-HTML key tells the storefront exactly what to drop, so the edit is live in seconds without a deploy.

What if my storefront endpoint is slow or down?

The webhook times out after 2 seconds and all errors are swallowed (and logged), so your admin save always completes. The content just refreshes on its normal TTL until the next successful purge.

Can one Magento publish to two storefronts?

Yes — put multiple comma-separated URLs in the Webhook URL field (per store view). Each unique endpoint receives one POST per purge, which is ideal during a Netlify→Cloudflare migration.

Is the webhook secure?

The secret is stored encrypted and sent as a Bearer token so your storefront can verify the caller; the manual REST purge endpoint requires an admin token. Verified clean on PHP 8.4 and 8.5.