Canvases and exports
All canvas-shaped read + export flows live under/v1/canvases and /v1/remix. Plus the share-token read pattern for public canvases and the /v1/share_links/resolve helper.
Endpoints
Listing and search
{data, next_cursor}). Sort is (created_at DESC, id DESC). See pagination.md.
List items include id, name, url, category, visibility, created_at, updated_at.
Reading a canvas
get_moda_canvas. Requires team access.
Reading a public share
POST /v1/share_links/resolve to parse a share URL first:
Tokens only
{variables, colors, fonts, radii, dimensions} — fast path for theme regeneration in CI.
Pages metadata
{canvas_name, total_pages, pages: [{page_number, name, width, height, node_count}]}. Call before GET /v1/canvases/{id}?page_number=N on multi-page canvases to plan per-page fetches.
Export — synchronous
Returns immediately:
Caching
Exports are cache-first. A repeat export of an unchanged canvas — sameformat, page_number, pixel_ratio, flatten — returns the previously rendered artifact with no new browser render. The source field reports how the response was served:
render— freshly rendered.cache— a previously rendered artifact was reused.slice— a single page extracted server-side from a cached full-document export (no render).
force_refresh=true only to skip the cache deliberately (e.g. you changed something the cache key doesn’t capture) — the default path is faster and cheaper.
Scope: designs:export and team membership. Share-token-only callers (no team access) cannot export — reads via share_token are not enough.
Export when a design task is running
If the target canvas has an in-flight design task, export returns:Retry-After seconds and retry. But in a task → export pipeline you often don’t need a separate export call at all: a programmatic design task auto-exports its result when it finishes, and the completion webhook payload carries it at data.result.export ({status, url, format, page_count}). Read that instead of polling, retrying the 409, or issuing your own export. The auto-export uses the canvas’s category-default format — pass export_on_complete to POST /v1/tasks to override the format or disable it.
Export is NOT a Task
Unlike design / remix / brand-kit extraction, exports don’t return a Task envelope today. Theexport kind exists in webhook event types (for future async export flows), but POST /v1/canvases/{id}/export itself is inline. Don’t poll /v1/tasks/{id} for an export.
Sharing — blocking thumbnail default
wait_for_thumbnail: false to skip if you don’t care about unfurls.
Remix
kind: "remix"). Without a prompt: the task is synchronous, returns status: "succeeded" inline, result.canvas_id is the new canvas. With a prompt: queues a design task on the copy, returns non-terminal; poll same as /tasks/{id}.
The source canvas is never modified.
Design-to-code walk
POST /v1/canvases/{id}/export?format=png.
Common wrong guesses
- Expecting
POST /v1/canvases/{id}/exportto return a Task envelope. Synchronous; returns{url, format, source}inline. - Passing
force_refresh=trueon every export. The default is cache-first — a repeat export of an unchanged canvas is served from cache with no render. Only force a refresh when you deliberately need to bypass the cache. - Issuing a separate export after a design task. A programmatic task auto-exports; the completion webhook carries it at
data.result.export. Re-exporting just hits the cache, but reading the webhook field is one fewer call. - Treating the
409 canvas_active_jobresponse as a bug. It’s the intended retry signal when chaining task → export. - Ignoring
Retry-Afteron the 409 response. Back off the suggested seconds; don’t hammer. - Using
share_token=to export. Only reads are permitted via share token. Export requires team access. - Skipping
wait_for_thumbnail: falseon/sharecalls in a script. By default it blocks — in a batch share-link generator, the latency adds up. Passfalseif you don’t care about unfurls. - Treating
GET /v1/canvases/{id}withoutpage_numberas cheap on multi-page designs. It returns all pages concatenated. - Holding an export URL longer than 7 days. Expires. Re-export if needed.
- Storing the
X-Request-IDheader from a successful export to use as an idempotency key. That’s what the body-fieldidempotency_keyonPOST /v1/tasksis for — exports don’t need it (stateless + fast).