The Canva Button — the embed that let your users design in a Canva overlay and hand the result back to your app — was discontinued for partners outside China after December 30, 2025. If it powered a feature in your product, you're not evaluating design tools for fun; you're replacing infrastructure a vendor switched off. This page covers what your options actually are.
Quick disclosure: you can guess why this page exists. We ship the Polotno Button — the same script-plus-button integration shape the Canva Button had — so we think the closest like-for-like replacement is ours. But a useful guide still has to tell you when a different path fits better, so this one does.
The short answer
Like-for-like embed
Users live in Canva
Background generation
What happened to the Canva Button
The Canva Button was a JavaScript snippet: your user clicked "Design with Canva," an overlay opened Canva's editor, and the finished export came back to your app through a callback. It made Canva's editor a feature of your product — which is exactly why so many SaaS tools, website builders, and internal platforms wired it in.
Canva discontinued the Button for partners outside China after December 30, 2025, and points integrators at the Connect APIs instead. Whatever the strategy behind it, the practical lesson is the one that matters for the rebuild: the Button was a free feature on someone else's roadmap, and features on someone else's roadmap can be turned off. The replacement decision is worth making once, properly, on terms you hold a contract for.
Why Connect APIs aren't a drop-in replacement
Canva's suggested migration path is real and well-built — but it's a different product shape, not the Button with a new name.
Users need Canva accounts
The Button let anonymous users design in your app. Connect APIs act on a Canva user's account — every user of your feature now needs to be a Canva user who grants your app OAuth access.
Editing happens on canva.com
There is no embedded editor in the Connect APIs. Your app can create designs, read them, export them, and deep-link users to the Canva editor — in Canva's tab, with Canva's branding, outside your product.
Designs live in Canva's cloud
The design data belongs to the user's Canva account, in Canva's format. Your product orchestrates around it; it doesn't own it.
The workflow breaks in the middle
The Button's loop was: click, design, export, done — all inside your app. The Connect loop is: authorize, deep-link away, hope the user finishes and comes back. For some products that's acceptable. For a design feature that drives your funnel, it usually isn't.
If your users are agencies and marketing teams who already live in Canva, Connect is a genuinely good fit — meet them where their assets are. If your users came to your product to design something, the redirect is where you'll lose them.
What a like-for-like replacement needs
Measured against what the Button actually did for your product:
This is the shape of an embeddable editor. Polotno ships it at two levels — and the first one is deliberately shaped like the thing you just lost.
The drop-in replacement — Polotno Button
The Polotno Button is the same integration contract as the Canva Button: add a script, wire a button, get an editor overlay, receive the export in a callback. A Canva Button integration maps onto it almost line for line:
<script src="https://embed.polotno.com/button-v1.js"></script>
<button id="polotno-button">Open editor</button>
<script>
document.getElementById('polotno-button').addEventListener('click', () => {
window.createPolotnoEditor({
key: 'YOUR_API_KEY',
// size, templates, and visible panels are configurable
onPublish: ({ dataURL, json }) => {
// the rendered image — same job as the Canva Button callback
// plus the design JSON: store it and reopen the design later
},
});
});
</script>The differences are the ones that caused this migration in the first place: no third-party accounts for your users, your choice of visible panels and templates, and onPublish hands you the design JSON alongside the image — so designs become re-editable data in your database instead of artifacts in someone else's cloud.
When the button outgrows itself — you want the editor as a page in your app rather than an overlay, custom side panels, or programmatic design generation — the same JSON moves to the full Polotno SDK: composable React components, an open schema, and rendering that runs client-side, on your servers, or through an optional cloud API. After six years and 300+ production integrations — including Amazon and BMW — the pattern is well-worn: teams replacing a Button integration typically ship within a sprint or two, not a quarter.
Migrating from the Button — the practical path
1. Inventory the Button's job
What did users design, at what sizes, from which entry points, and what format did your callback consume? That list is your integration spec.
2. Swap the script
Replace the Canva Button script with the Polotno Button script and move your callback logic into onPublish. This is the like-for-like step — same entry point, same overlay flow, same "here's your image" hand-back.
3. Replace templates
Canva's template library didn't transfer through the Button anyway — designs started in Canva's ecosystem. With Polotno you supply templates as JSON (jsonUrl on the Button, or your own template picker on the SDK). Most teams start with a dozen governed templates per use case, which converts better than a blank canvas ever did.
4. Keep the JSON from day one
Store the design JSON that comes back with every export. It's the upgrade the Canva Button never offered: users can reopen and edit past designs, and you can re-render them server-side — which is also your painless upgrade path to the full SDK later.
Other options, honestly
Adobe Express Embed SDK — the closest thing to "another Button": Adobe's hosted editor in an iframe, free to integrate, Adobe-branded, designs in Adobe's cloud. If you're comfortable re-creating the same dependency with a different logo, it's a fast path. See our detailed comparison.
Picsart Creative SDK — embeddable editing with a photo-editing center of gravity. Worth evaluating if your Button usage was mostly image touch-up rather than layout design.
Render APIs (Templated, Bannerbear, Placid) — no interactive editor, but if your Button flow had degenerated into "apply template, change one line of text, export," a render API may be the honest replacement. See Polotno SDK vs Templated.
Build in-house on Fabric.js or Konva.js — full control, no license fee, and a year of editor engineering before feature parity with what the Button did on day one. We maintain Konva; we say this with affection. The build-vs-buy breakdown runs the numbers.
FAQ
Is the Canva Button coming back?
Canva's developer messaging points integrators to the Connect APIs. Nothing suggests the embedded Button returns for partners outside China.
Can I keep designs my users made through the Button?
Exports you already received are yours. The underlying designs live in Canva's ecosystem — one more argument for owning design data in the next integration.
How close is Polotno to what the Button did?
The Polotno Button is the same integration shape — script, button, editor overlay, export callback — so the user-facing loop is identical. The differences are all on your side of the ledger: your branding, your data (including the design JSON), no user accounts with a third party, and a paid license with contractual terms instead of a free feature that can be sunset.
How long does the migration take?
The editor embed is typically days; template creation and export wiring are where real scope lives. Teams replacing a straightforward Button integration usually ship within a sprint or two. The 60-day trial covers the evaluation comfortably.
