Astro ISR Purge

VIDEO WALKTHROUGH

Astro ISR: setup guide

2:24

Recorded on version 1.0.3 · Narrated walkthrough · English captions

Jump to a chapter 7 chapters

1. 0:00Set up Astro ISR
2. 0:17Open the ISR configuration
3. 0:38Set the receiver endpoints
4. 1:00Match the shared secret
5. 1:22Check Redis with your developer
6. 1:42Save, then verify a controlled change
7. 2:06Your setup checklist

Read the full video transcript

Astro ISR 1.0.3 — Magento Admin setup

00:00:00 — Set up Astro ISR
Welcome to the Agentic Ecom Astro ISR guide. We'll use Magento Admin to review the setup and explain the handoff to your headless storefront. This walkthrough covers stable version 1 point 0 point 3 and assumes the extension is installed.

00:00:17 — Open the ISR configuration
Open Stores, Configuration, Astro ISR. This module tells the storefront when Magento content changes, using purge webhooks and the configured Redis channel. Before enabling it, your developer needs to deploy a compatible webhook receiver and configure its hosting-specific cache purge.

00:00:38 — Set the receiver endpoints
Under General Settings, Enable ISR Purging reveals the webhook fields. Astro Webhook URLs accepts one endpoint, or a comma-separated list for multiple targets. Use the receiver address provided for your storefront. The example path is api, webhook, magento-purge; it must actually exist on your deployment.

00:01:00 — Match the shared secret
Set Webhook Secret to the same secret used by the receiving Astro application. This stable release sends the secret as a Bearer token. Keep it private and configure it identically for every listed receiver. Our recording conceals secret values. Debug Logging is useful while diagnosing a problem, and should normally be off in production.

00:01:22 — Check Redis with your developer
Open Redis Settings. Confirm the host, port and channel used by your deployment. The default port is six three seven nine. These are infrastructure details, so use the actual connection your hosting environment provides. A Redis configuration alone does not replace the storefront webhook receiver.

00:01:42 — Save, then verify a controlled change
Save the configuration in staging. Make a controlled product or C M S change and inspect the receiver and Magento logs for the expected purge. Confirm the storefront serves the new content. Purging and prebuilding are distinct parts of the deployment, so check your storefront's refresh strategy as well. We are showing the controls here, without sending a live purge.

00:02:06 — Your setup checklist
Your next steps are to deploy the compatible receiver, match secret and redis settings, verify a controlled staging change. Use a staging store for the end-to-end check. The complete installation and integration reference is at user guides dot Agentic Ecom dot net.

Download videoEnglish captionsDownload transcript

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: a configured edit sends a tagged purge webhook and relevant prebuilt HTML keys to your storefront. Confirm that your receiver clears those keys and serves the updated content; webhook delivery and cache behavior determine when the change appears.

Version 1.0.3 gives this module its own Admin configuration tab, so the settings remain available when AgenticEcom Core is absent.

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).

Install

Install Astro ISR Purge with Composer using your AgenticEcom licence key (find it on your My Licences page — one key unlocks every module you own):

# 1. Register the AgenticEcom repository (once per store)
composer config repositories.agenticecom composer https://repo.agenticecom.net
composer config --global --auth http-basic.repo.agenticecom.net <YOUR-LICENCE-KEY> x

# 2. Require this module
composer require agenticecom/module-astro-isr

# 3. Apply it
php bin/magento setup:upgrade && php bin/magento setup:di:compile && php bin/magento cache:flush

Have the whole platform?

Install every module in one command with composer require agenticecom/suite — see Install the complete suite.

Compatibility

Magento

Check the exact release against your Magento Open Source version.

PHP

Check the exact package requirements and test your PHP version.

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. A receiver can then serve updated content without a full-site rebuild when that fallback is configured.

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 can refresh it when the subscriber is connected.

Check failed purges

The webhook has a 2-second timeout and errors are caught and logged, so a failed purge does not throw a save error. A slow receiver can still add time within that timeout. Monitor failures and confirm when the normal cache TTL or a later purge exposes the edit.

Configuration

Stores → Configuration → AgenticEcom Astro ISR → Astro ISR

Group	Key settings
General	Enable (per store view), Astro 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. Use HTTPS webhook URLs without embedded credentials or query-string secrets. Distinct URL and secret pairs are kept separate when several receivers are configured.

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?

A configured receiver can clear the affected tags and prebuilt HTML keys without a full-site deploy. Check the resulting page: delivery, cache rules and fallback rendering control how soon the edit appears.

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 is not rejected by that webhook error. The page may remain stale until a cache TTL, a manual purge or a later successful request updates it.

Can one Magento publish to two storefronts?

Yes — put multiple comma-separated HTTPS URLs in the Webhook URL field (per store view). Each configured URL and secret pair receives a POST per purge, which supports a migration between receivers.

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. Check exact-release compatibility before deployment.