Canva and CodeWords: templates, autofill, and the brand problem

Canva exists because most people producing marketing material are not designers, which is also the reason automating it is worth doing. The repetitive work — the same layout with different words and a different image, forty times — is exactly what a person should not be doing by hand, and exactly what produces inconsistency when they do.

The mechanism is brand templates with defined fields, filled programmatically. Understanding what that supports, and what it does not, determines whether this is a week of work or a month of disappointment.

What we'll cover

• Templates with fields, not arbitrary editing
• What the Canva Connect API reaches
• Asynchronous by nature
• Connecting it to CodeWords
• Seven automations worth building
• Brand consistency, which is the actual goal
• Where the source content should live
• Review, and who signs off on what
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

Templates with fields, not arbitrary editing

The model is important and it is narrower than "automate design".

Brand templates define named fields — text and images — and autofill supplies values for them. That is the supported path for generating designs programmatically.

Layout is fixed. You are filling a design somebody made, not composing one. This is a feature: it is what keeps forty generated assets consistent.

Text length matters. A field designed for four words given forty will overflow or shrink, and the generated design will look wrong without anything reporting an error.

Images need to suit the frame. An image with the wrong aspect ratio crops in ways nobody chose.

Some capabilities depend on plan and on your integration's approval, so confirm what you have before scoping.

The practical implication: the design work happens once, in the template, with a person who knows what they are doing. Everything afterwards is supplying values, and the value supplied should be validated against what the template expects.

What the Canva Connect API reaches

Brand templates can be listed with their available fields, which is how you discover what a template accepts rather than guessing.

Autofill creates a design from a template with values for its fields, returning a job to poll.

Designs can be listed and read, and their metadata retrieved.

Exports produce files in various formats, asynchronously.

Asset upload puts images into Canva for use in designs.

Folders organise designs, which matters once generation produces volume.

Comments can be read and created on designs, which is a route for review feedback.

Webhooks notify on certain events where available, reducing the need to poll.

Asynchronous by nature

Nearly everything interesting here is a job rather than a response, and automation that assumes otherwise breaks immediately.

Autofill returns a job identifier. The design is not ready when the call returns.

Export returns a job too, and rendering takes time proportional to complexity.

Poll with backoff, and set a sensible overall timeout, since a complex design takes longer than a simple one.

Handle failure explicitly. A job can fail, and the reason matters — an oversized image, an invalid field, a template that has changed.

Download links expire. Retrieve the file promptly and store it where you need it rather than keeping the link.

Plan for the wait in your process. A generation pipeline producing forty assets is minutes rather than seconds, which is fine if the process expects it.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which template, where the values come from, and where the exported file should go.
3. Authorize the connection to the Canva account holding the templates.
4. Describe the exceptions: text too long for a field, an image of the wrong shape, an export that fails.
5. Generate a handful and look at them before running a batch of hundreds.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Bulk generation from a data source. A spreadsheet or a database of products, events, or properties producing one asset each, consistently branded.

Personalised assets at scale. Per-customer or per-territory variants that would never be made by hand because the volume makes it impractical.

Social posts from published content. When something is published, generate the accompanying image from the template rather than asking a designer for it.

Certificates and credentials. Completion documents generated and delivered, which is a common need and entirely mechanical.

Sales collateral per account. One-pagers with the right logo, the right figures, and the right contact, produced when an opportunity reaches a stage.

Asset delivery to where they are used. Exported files placed in the content system, the ad platform, or the shared drive, rather than left in Canva.

Template usage reporting. Which templates are used and which are not, so the library reflects what people actually need.

Brand consistency, which is the actual goal

The reason to build this is rarely speed alone.

Generated assets cannot drift. A template filled programmatically produces the same layout every time, which a person recreating it from memory does not.

Approval happens once, on the template. Rather than on every asset, which is where design review time disappears.

Validate the inputs, not the outputs. Checking text length and image dimensions before generating catches nearly everything that would look wrong afterwards.

Keep the template set small. A library of two hundred templates has the same inconsistency problem as no templates at all, because nobody can find the right one.

Retire templates deliberately. Usage reporting tells you which are dead, and removing them makes the rest findable.

Leave the design to designers. The value of this automation is that it stops non-designers improvising, so an automation that lets them improvise faster has missed the point.

Where the source content should live

Not in Canva. The values filling the template — product names, prices, dates, descriptions — belong in whatever system owns them.

One source per field, so a price appearing on an asset comes from the same place as the price on the website.

Regenerate rather than edit. When the source changes, generate a new asset rather than editing the old one, so the asset always reflects the source.

Record what was generated from what, including the template version and the source record, which is what makes it possible to find every asset affected when something was wrong.

Expire generated assets where they contain time-sensitive information, since an out-of-date price on an asset still in circulation is a real problem rather than an aesthetic one.

Review, and who signs off on what

Generated assets still go out with your name on them, and the review step is where most implementations are either too heavy or absent entirely.

Review the template, thoroughly, once. That is where design, brand, and legal attention belongs, because every generated asset inherits it.

Spot check the batch, do not review every item. A sample from a generated set catches template problems; reviewing four hundred individually defeats the purpose.

Automate the checks a person would do badly. Text overflow, missing values, an image that failed to load — a machine catches these more reliably than somebody looking at the fortieth variant.

Escalate what fails, not what passed. A review queue containing only the problem cases is one somebody actually works through.

Keep a person in the loop for anything public and consequential — a campaign, a price, a claim — where the cost of being wrong is not an aesthetic one.

Record who approved the template and when, since that is the approval that covers everything generated from it.

Building it so it survives

Read the template's fields rather than hard-coding them, since templates are edited and a renamed field breaks generation.

Validate before generating. Text length and image aspect ratio, checked against what the field expects.

Make generation idempotent. Key on the source record and template version so a retry does not produce duplicates.

Retrieve exports promptly, since download links do not last.

Report the outcome. Assets generated, failures with reasons, and anything skipped for failing validation.

Limits worth knowing about

Rate limits apply and bulk generation needs pacing rather than firing everything at once.

Autofill requires brand templates, which depend on your plan — it does not work against arbitrary designs.

Field types are constrained to what the template defines, so anything beyond text and images needs a different approach.

Export formats and quality options vary by design type, and not every combination is available.

Download links expire, which catches out any pipeline that stores the link rather than the file.

What to build first

Bulk generation from whichever data source already exists: one asset per row, from an approved template, exported to where the assets are used. It removes the most tedious design work in the organisation and it produces output nobody has to check for brand consistency.

Two habits make the difference. Validate text length before generating, since overflow produces a design that is wrong and does not error. And generate a small batch and look at it properly before running the full set, because a template problem multiplied by four hundred is a bad afternoon.

Frequently asked questions

Can automation create designs from scratch?

No. The supported path is filling a brand template with defined fields, which is a deliberate constraint and the reason generated assets stay consistent. Composition happens once, by a person, in the template.

Why does a generated design look wrong?

Almost always input that did not suit the field — text longer than the design allows, or an image with the wrong aspect ratio. Neither produces an error, which is why validating inputs before generating is the thing that makes this reliable.

How long does generation take?

Longer than a request. Autofill and export are both asynchronous jobs, and a batch is minutes rather than seconds. Design the process around that rather than expecting an immediate file.

Where should the content come from?

Whatever system owns it. Prices, names, and dates should come from the same source as everywhere else they appear, and the asset should be regenerated when that source changes rather than edited.

Do I need brand templates?

For autofill, yes, and they depend on your plan. It is worth confirming before scoping the work, since the whole approach rests on them.

How do I keep track of what was generated?

Record the source record and the template version against each asset. When something turns out to be wrong — a price, a name, a logo — that record is what tells you which assets are affected and where they went.

Can this replace a designer?

No, and it is not trying to. It removes the repetitive filling-in, so the designer's time goes into the template and the things that need judgement rather than into the fortieth variant of the same layout.

How should generated assets be reviewed?

Review the template thoroughly once, since everything inherits it, then spot check batches and automate the mechanical checks — overflow, missing values, failed images. A review queue containing only the failures is one people actually work through.

Who is accountable for a generated asset?

Whoever approved the template, which is why recording that approval and its date matters. Per-asset sign-off does not scale and produces worse review than a careful template approval plus automated input validation.

Related reading

• Figma and CodeWords
• Miro and CodeWords
• CodeWords integrations and templates