Canva Frontend ↔ REST API: Handling Stale Export Status After Design Edits

Question

Canva Frontend ↔ REST API: Handling Stale Export Status After Design Edits
The goal is to ensure that, immediately after a user edits a design, the UI reflects the current export status rather than a previously cached response.
Canva’s /v1/designs/:id/export endpoint returns JSON with a max‑age of up to 24 hours and does not include stale‑while‑revalidate, so browsers may serve an outdated status when a design has just changed. The unresolved decision is whether Canva should add explicit cache‑busting tokens (e.g., a version query parameter) to these mutable API responses, or rely on clients to send Cache‑Control: no‑cache headers, leaving the behavior dependent on each implementation.
Should Canva append a version token to export API URLs for mutable resources? Should the API require or encourage clients to include Cache‑Control: no‑cache for export status requests? What are the trade‑offs between server‑side cache busting and client‑side header reliance in terms of performance, compatibility, and control?

Tasadduq Burney · Answer

Immediate Answer
Use a design‑specific version token (?v=designVersion) on the export URL. Combine it with Cache‑Control: no‑cache for the first request after an edit, and let the server emit ETag/Last‑Modified headers to preserve bandwidth on subsequent polling.
Why a Version Token?

Each edit produces a new token, forcing browsers and CDNs to treat the response as a distinct resource.
It removes the need for clients to remember to set Cache‑Control: no‑cache on every request.
When the CDN preserves query strings in its cache key, the token guarantees freshness without extra round‑trips.

Why Not Rely Solely on Cache‑Control: no‑cache?

Browsers and intermediaries may ignore the header if they implement aggressive caching or have mis‑configured policies.
Every request bypasses the CDN, increasing origin load during peak editing sessions.
It places the burden on the client to remember to set the header consistently.

Best‑Practice Combination

Server‑Side:

Append ?v=designVersion to the export URL for each design edit.
Emit ETag or Last‑Modified headers with the export response.
Ensure CDN cache keys include query strings; validate in the CDN console.

Client‑Side:

On the first poll after an edit, send Cache‑Control: no-cache to force a fresh fetch.
For subsequent polls, rely on ETag/Last‑Modified to perform conditional GETs (If‑None‑Match or If‑Modified‑Since).
Store the design’s current version token and use it for all future export status requests until the next edit.

Monitoring:

Log the Cache‑Control, ETag, and Last‑Modified headers in a sample of responses.
Verify that the CDN is not stripping the query string by inspecting cache hit/miss metrics.

Missing Diagnostic Detail
To confirm that the version token will actually invalidate stale cache entries, please provide the current CDN configuration for the /v1/designs/:id/export endpoint. Specifically, does the CDN include query strings in its cache key, or does it strip them before caching?

Canva Frontend ↔ REST API: Handling Stale Export Status After Design Edits

Canva Frontend ↔ REST API: Handling Stale Export Status After Design Edits

1 answer

Immediate Answer

Why a Version Token?

Why Not Rely Solely on `Cache‑Control: no‑cache`?

Best‑Practice Combination

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments