Do Shopify Video CDN URLs change after transcoding? (Caching strategies for apps)

GraphQL Admin API Troubleshooting
1

Hi all,

We’re building a high-traffic shoppable video app. Merchants import/upload videos, which we store as Shopify Files (Video media type). Once transcoding completes (fileStatus: READY), we cache the resulting CDN source URLs (sources[].url for SD/HD/HLS renditions) directly in our DB, keyed by the file/media GID.

We do this to avoid hitting the GraphQL Admin API on every storefront pageview, which wouldn’t scale under high traffic.

I’d love to confirm a few architectural points with the community and Shopify team:

  1. Do the CDN URLs under sources for a given Video file ever change after initial transcoding completes (e.g., due to background re-processing, CDN domain/key migrations, or url expiration) assuming the merchant doesn’t touch the file?
  2. If they can change, is there a recommended way to detect it (a webhook, a shopifyUpdatedAt check, etc.) rather than polling GraphQL for every file on a schedule?
  3. Is caching these URLs long-term (keyed by GID) an intended/supported pattern, or does Shopify expect apps to always resolve fresh from the GID at render time?

Trying to make sure our architecture aligns with Shopify’s expectations. Thanks in advance!

3

Hey @Shreyash_Matele - thanks for raising this.

The existing CDN guidance recommends fetching current file URLs rather than caching hardcoded CDN URLs: Replacing or deleting a Shopify-hosted file no longer purges its CDN URL - Shopify developer changelog. It doesn’t explicitly cover whether video sources can change after background reprocessing or whether updatedAt provides a reliable invalidation signal.

I’m digging in here to confirm the supported behaviour and caching pattern for this use case. I’ll follow up here once I have more information to share.

4

Hey @Shreyash_Matele - thanks for your patience while I looked into this for you.

Under the current behaviour, Shopify videos can’t be updated in place. Once a video reaches fileStatus: READY, its SD, HD, and HLS URLs should remain stable and accessible for as long as the file exists.

If you cache sources[].url, we recommend using a reasonable TTL. There isn’t currently a Files webhook for cache invalidation. That’s useful feedback, and I’ll add this use case to the existing feature request for Files webhooks:

If a file is deleted, treat its URLs as invalid even if CDN caching keeps them reachable temporarily.

Hope this helps!