Pro plan

Dynamic links (replacing content)

Swap the document behind an existing share link without changing the link, and use it to restore burned documents.

Dynamic links let you replace a document's content in place—upload a new PDF to an existing link without changing the link itself. The UUID, short ID, vanity slug, QR code, embed code, all settings, and your complete readership history survive the swap. What changes is the document itself, and by default the decorations anchored to its pages.

This is useful when you need to update a shared link with a newer version of a document, correct an error, or restore a burned link to active status.

What survives a content replacement

When you replace a document's content, everything about the link persists:

  • Identifiers: UUID, short ID, vanity slug (if set), and any link variants
  • Sharing artifacts: QR codes and embed code snippets remain valid; no need to re-distribute them
  • Settings: Password protection, expiry date, view limits, page ranges, watermarks, and all other document settings stay in place
  • Readership data: Viewer sessions, captured emails, page-level statistics and every other readership record survive unchanged
  • Link history: The document maintains a revision history recording each superseded version

Three things do change besides the bytes. The filename and file size become those of the new document. The page count is recalculated. And the counter behind the view limit resets to zero — the limit itself is kept, so it applies afresh to the new document. Page-anchored decorations are the fourth, and they are described below.

This makes content replacement ideal for published documents—a printed QR code or an embed already deployed on another site continues to work after you swap the content.

How to replace content

Open any document in your library and go to the sharing panel. In the "Replace File" section, choose a new PDF (or Word/PowerPoint document if Office conversion is enabled). If the current document has page-anchored hotspots or comments, you are prompted to decide whether to keep or clear them. Confirm the replacement, and the new document is uploaded and served immediately from the same link.

Page-anchored decorations and the clearAnchors option

By default, content replacement clears page-anchored hotspots and comments because the new document may have a different number of pages or layout. These decorations are anchored to specific page numbers, which may no longer make sense with new content.

The behaviour is controlled by a clearAnchors query parameter on the replacement endpoint. It defaults to true; passing clearAnchors=false (or clearAnchors=0) keeps the anchored decorations. In the interface, the choice appears as a prompt — but only when the current document actually has hotspots or page comments to strand. With none, replacement proceeds straight away.

Document-level notes (comments not tied to a specific page) always survive a replacement, regardless of this setting.

Keeping anchors is intended for a minor update — a corrected version of the same document with the same pagination — such as fixing a typo or refreshing a graphic. Note that keeping them keeps all of them: no filtering is applied to the new page count, so an anchor pointing past the end of a shorter replacement document is retained and will simply never be reachable.

Revision history

Every time you replace a document's content, a revision record is written for the version being superseded. It records that version's number, filename, file size and page count, together with the time the replacement happened. The sharing panel lists this history newest first, and a version badge (v2, v3, …) appears beside "Replace File" once a document has been replaced at least once.

The revision record describes the document, not who read it. Readership records are not partitioned by content version, so the history tells you what each version was, not which version a given reader saw.

Restoring burned documents

If a document reaches its view limit and burns—becoming inaccessible to new viewers—you can restore it to active status by replacing its content. Upload a new document (or the same one again), and the link returns to life: the burned marker is cleared and the consumed-views counter resets to zero, so the existing view limit starts over. The UUID and all readership records survive.

Content replacement accepts burned documents on purpose — it is the un-burn path, and every other write to a burned document is refused with a 410.

Expired documents are the deliberate asymmetry: replacement refuses them with a 410, both before the upload begins and again immediately before the swap is committed. An expired link has reached its time-based deadline and is queued for deletion, so it cannot be revived; create a new link instead.

Availability and permissions

Content replacement is a Pro feature available to document owners only. Anonymous uploads cannot use it: the manage tokens issued alongside an anonymous or Canva upload act as a free-tier caller, so the Pro gate refuses them. Claim the document into a Pro account first.

API keys and OAuth tokens holding the files:write scope can call the endpoint on behalf of a Pro owner, at /api/v1/files/{uuid}/content. The uploaded document is bounded by the owner's plan size cap, and PDF, Word and PowerPoint files are all accepted where Office conversion is available — the same rules as a normal upload.

Webhook events

When you replace a document's content, EveryPage emits a content.replaced webhook event if you have webhooks configured. Its data carries the new content version alongside the document's UUID and filename. The API response itself is more detailed: it also returns the new size, whether anchors were cleared, and how many hotspots and notes were removed.

For details on subscribing to webhook events, see Webhooks.