Skip to main content
Embedded override mode is the pattern for template-driven products: you maintain one base composition HTML file and store only the per-instance delta (the OverrideSet) alongside it. When a user edits their instance, the SDK accumulates further changes into that same delta — the base stays untouched. This is exactly how a canvas embedder (for example, AI Studio) persists in-composition edits as a stable, reopenable delta.

Opening with overrides

Pass the stored delta as overrides when you call openComposition. The SDK replays the override set onto the base template in one pass, so the session exposes the user’s exact edited state immediately:
After openComposition returns, comp.getElements() reflects the overridden state. Any further edits accumulate into the same delta automatically.

Reading the current delta

Call getOverrides() to retrieve the current delta for storage. It returns a shallow copy of the internal override set — safe to serialize and stash:
On the next session open, pass nextOverrides as overrides again — the user sees their exact state.

Override set key format

Keys follow the pattern hfId.prop.path. The common forms are: A null value is a removal marker. When the SDK serializes the composition it omits that element entirely. This lets the host distinguish “never touched” (key absent) from “user deleted” (key present, value null). Sub-composition elements use scoped IDs — "hf-host/hf-leaf.text" — where the host and leaf are separated by /.

Font and image variable overrides

Variable overrides (from setVariableValue) live under the var.{id} key. Font and image values are objects, not strings:
When you read an OverrideSet value at a var.* key, narrow before treating it as a scalar — the type is string | number | boolean | Record<string, unknown> | null.

Disabling SDK undo

In embedded mode the host typically owns the undo stack. The SDK already leaves history off by default in embedded mode (any session opened with overrides), so you usually don’t need to do anything. Pass history: false explicitly only to make that intent obvious in standalone code paths, or as a guard if a call site may or may not supply overrides:
history: false only disables the SDK’s internal undo stack. Persistence (the persist adapter, if you supply one) is independent — omitting it does not affect autosave. In embedded mode, however, the host typically owns both undo and persistence, so you usually pass neither.

Host-owned undo via applyPatches()

When the host pops an undo entry and needs to replay the inverse patches back into the SDK, use applyPatches(). The SDK applies the patches to the live document, updates the internal override set, and emits a patch event tagged with ORIGIN_APPLY_PATCHES.
applyPatches() accepts an optional opts.origin override if you want to tag the event with a different sentinel, but the default ORIGIN_APPLY_PATCHES is the expected value for host undo/redo flows. See Undo, Redo, and Patches for the full patch event contract and inverse patch handling.

Full example

openComposition reference

Full OpenCompositionOptions including overrides, history, and persist.

Types reference

OverrideSet, FontValue, ImageValue, PatchEvent, and ORIGIN_APPLY_PATCHES.

Undo, Redo, and Patches

Patch event format, inverse patch contract, and undo loop prevention.

Canvas integration

Wiring the SDK to a live preview iframe inside an editor canvas.