Why changes take time to appear
Why a change you saved in the admin can still show the old version on the storefront or checkout, and how to force a refresh.
You changed something in the admin — activated a campaign, edited an offer, tweaked a discount — but the storefront or checkout still shows the old version. This is almost always a timing issue, not a lost change. Llama Upsells stores your rules in Shopify metafields, and writing to those metafields happens in the background. This page explains exactly how the sync works, why a delay can stretch from seconds to longer, and how to force an immediate refresh.
The short version: your change was saved, but it propagates to the storefront asynchronously. Give it a few seconds, reload, and if it is still stale use the Sync action on the campaign to push the latest data and clear the cache.
The sync model
The app does not call its own backend at checkout. Instead, it writes your rules into Shopify metafields, and the checkout extensions and widgets read from there. This is what makes checkout fast and reliable — but it also means there are two separate steps: you save in the admin, and then the data is pushed out to where the storefront can read it.
There are three distinct read paths, and they refresh differently:
| Read path | Who reads it | Source | Refresh behavior |
|---|---|---|---|
| Checkout extensions | Product discount, cart validation, restrictions, products limiter | Shopify metafields, read directly at checkout | No backend call; reflects the latest metafield value once the push completes |
| Storefront widgets | Pre-purchase, Gift with Purchase, Llama Cart blocks | Campaign data served through the proxy | Served from the proxy's in-memory cache (cleared on campaign update, but has a TTL) |
| Promo-code-triggered campaigns | Code-based campaigns | App server endpoint | Evaluated live by the server, not from metafields |
What triggers a metafield write
The server writes to metafields on every create, update, delete, or status change for the data each extension depends on. Specifically, a sync runs when you:
- Activate or deactivate a campaign — the active-campaigns list is rewritten.
- Edit a campaign's conditions or offers — the compressed campaign payload is rewritten.
- Edit a restriction — the cart-validation restriction rules are rewritten.
- Edit a discount — the automatic-discount and tier-discount data is rewritten.
- Edit a product limiter — the per-product quantity caps are rewritten.
Each of these saves pushes fresh data to the relevant metafield. Because the extensions read metafields with no backend call, once the write lands, checkout sees the new rules on the next evaluation — no further action needed.
Promo-code-triggered campaigns are the exception to the metafield model. They are evaluated through the app's server, not read from metafields, so they are not affected by metafield sync timing. See Promo code triggers for how those work.
How long it takes
Under normal conditions, a change reaches the storefront in seconds. When it takes longer, it is almost always one of four caches or queues in the chain, each for a specific reason:
The asynchronous push has not finished
When you click Save, the admin confirms immediately, but the metafield write to Shopify happens in the background. For the brief window before that push completes, the old rules are still the live ones. This is normal and self-resolves within seconds.
The proxy is still serving a cached campaign payload
Storefront widgets read campaign data through the proxy server, which keeps an in-memory cache to stay fast under load. The cache is cleared automatically when a campaign is updated, but it also has a time-to-live (TTL). If the cache entry has not yet been cleared and has not yet expired, the proxy can keep serving the previous payload for a short time.
Shopify or the CDN is caching the storefront page
Your theme pages are served through Shopify's CDN. A cached version of the page (and the widget markup it contains) can be served to a shopper even after your data has updated. This clears on Shopify's own schedule when the page is next regenerated.
Your browser cached the old version
The browser you are testing in may have cached assets or a previous response. This is the most common reason a change "isn't showing" for the person who made it, while it is already live for everyone else.
These four layers stack. If a change still looks old, it is rarely a single cause — the asynchronous push may have completed while your browser or the CDN is still serving an old copy. Always rule out your own browser cache (test in incognito) before assuming the data did not sync.
Force a refresh: the Sync action
When you do not want to wait for the caches to clear on their own, the Sync action republishes the campaign's data to Shopify metafields and clears the proxy's cache for that campaign in one step.
Open the campaign list
Go to Campaigns in the app's admin to see all of your campaigns.
Run the Sync action on the campaign
Use the Sync action on the campaign whose data looks out of date. This republishes its rules to the Shopify metafields and clears the proxy's cached payload, so the next storefront read returns the fresh data.
Reload the storefront and re-test
Give it a few seconds, then reload the storefront or checkout — ideally in an incognito window so your browser cache is not in the way.
Use Sync when:
- A recent edit to conditions, offers, a discount, a restriction, or a limiter is not reflected on the storefront after waiting.
- You just re-activated a campaign and it has not reappeared.
- You just downgraded your plan (see the special case below).
Plan downgrade is a special case
Downgrading is the one scenario where a manual Sync is genuinely required, not just a shortcut.
When you downgrade to a plan with a lower campaign limit, the app auto-deactivates the campaigns that exceed the new limit, newest first, until you are back within the allowance. The catch is that no metafield sync runs during that deactivation batch. The campaigns are marked inactive in the admin, but the metafields the storefront reads are not rewritten as part of the downgrade.
The practical effect: a campaign that was deactivated by the downgrade can keep displaying on the storefront until the next time you save any campaign (which triggers a normal sync) or until you run a manual Sync.
After a plan downgrade, manually Sync the affected campaigns (or save any campaign) to push the deactivation out to the storefront. Otherwise campaigns you no longer have access to can keep showing to shoppers. Restrictions and product limiters are not auto-deactivated on downgrade, so they are unaffected.
For how downgrades, deactivation order, and reactivation behave end to end, see How features interact and Plans and billing.
Rate limiting (429) can delay storefront data
The proxy that serves storefront widget data is rate-limited per shop using a token-bucket strategy. On a high-traffic store, a sudden burst of widget requests can exhaust the available tokens, and the proxy responds with 429 Too Many Requests until the bucket refills.
Widgets are built to degrade gracefully when this happens. Instead of crashing or showing a broken block, a widget that receives a 429 (or any unparseable response) falls back to an empty or default state. On the next page load, when the bucket has refilled, the widget recovers and renders normally.
This means a widget that briefly disappears under heavy traffic is often rate-limiting, not a misconfiguration. It self-heals on the next load. If a widget is reliably missing on every load — not just intermittently under load — that points to a configuration or targeting problem instead. See Widget not showing.
Clear cache and test cleanly
Most "it didn't update" reports disappear with a clean test. Work through this checklist before escalating:
- Wait a few seconds after Save. The metafield push is asynchronous; give it a moment to complete.
- Reload the storefront page. A simple reload clears the most common stale-render cases.
- Test in an incognito / private window. This bypasses your browser cache entirely and is the fastest way to tell whether the data is actually stale or just cached in your browser.
- Re-run the Sync action on the campaign if it is still stale after a reload, then re-test.
- Test in a fresh cart. Checkout extensions evaluate against the current cart; an old cart can mask a change. Start a new cart and add the relevant products again.
Still stale after Sync?
Related
How features interact
Evaluation order, precedence, and how plan downgrades deactivate campaigns.
Metafield storage limit
Why large or numerous campaigns can hit Shopify's metafield character cap.
Why a discount doesn't apply
Diagnose discounts that don't show up at checkout, including sync timing.
Plans and billing
Plan limits and what happens to your campaigns when you upgrade or downgrade.
Multi-currency & markets gotchas
How money-based rules convert across currencies and markets, and the international-store gotchas merchants hit most.
Metafield size limits & many active campaigns
Why some campaigns stop showing after you add more, the metafield warning banner, and how each feature handles overflow.