FlowRunner
PricingContact
Theme
Start Free

Copicake

Developer Tools

Render saved image templates through the Copicake API with your own text, images, QR codes, and shape colors. Agents produce on-brand visuals per record without a designer in the loop.

4 actions API key available
Vendor Platform ↗ Capability data verified 2026-07-31
A registration record reaches Confirmed in the events table
Agent reads the attendee name, ticket tier, and redemption code from the record
Upload Temporary Image places the attendee headshot where the template's image layer can reach it
Create Image renders the ticket and writes the redemption code into the QR layer
Get Rendering polls until the rendering leaves processing and reports success
Save Rendered Image stores the first ticket and posts it to the events channel
The event lead scans the sample code, confirms it resolves to that attendee, and releases the rest of the batch

What This Integration Enables

Copicake turns a saved design into an endpoint. A designer builds the layout once in the Copicake editor and names the layers, and from then on an agent supplies values: headline text, a swapped image, a QR code payload, a shape color. The template is the contract, so nothing an agent does can move a logo or change a typeface. That is the whole point of rendering through a template rather than assembling an image from scratch, and it is why brand consistency survives volume.

What separates Copicake from a generic image renderer is that its per-record variable is frequently something a person will act on. A QR code is not decoration. It is a working key that opens a page, admits someone to a room, or redeems a value, and it is rendered from a field on a record. Copicake renders asynchronously, so Create Image returns a rendering id with the status processing and an empty permanent URL, and the image appears once the status becomes success. Agents can wait inline, poll with Get Rendering, or let a Copicake webhook deliver the rendering id when it is ready. FlowRunner's job in that loop is to make sure the value inside the code was checked by a person before the batch runs, which is what human-in-the-loop means on an asset that cannot be recalled once it is scanned.

Without FlowRunner

A design request per asset Every tier, every reissue, and every late name change goes back into the design queue
Codes moved by hand Someone copies redemption codes into a graphics tool one attendee at a time
No proof before the run The first person to notice a bad code is the person holding the ticket

With FlowRunner

One approved layout The design is signed off once and the API only swaps the values inside it
Codes written from the record The QR layer is filled by the same record that issued the code
A scanned sample first One asset is checked against the real scanner before the rest of the batch renders

Use Case Scenarios

Ticket issuance from the registration table

Registrations land in Airtable and reach Confirmed after payment clears. For each confirmed record the agent uploads the attendee photo to Copicake temporary storage, calls Create Image against the approved ticket template with the attendee name, tier, and the redemption code that record already holds, then polls Get Rendering until the render succeeds. Save Rendered Image pulls the finished file into FlowRunner storage so the same asset can be attached to an email through SendGrid and archived without depending on a vendor URL. The design queue is involved once, at the beginning, rather than once per event.

Completion certificates issued on the day they are earned

A learner finishes a course and the record flips to Complete. The agent renders a certificate from the approved template with the learner name, the course title, the completion date, and a QR code pointing at the verification page for that specific certificate. It saves the file, attaches it to the learner record, and posts the delivery confirmation to the team channel in Slack. Certificates stop being a monthly batch someone assembles and become a side effect of the record changing.

Per-record campaign images built from data generated inside the flow

An agent produces a chart or a product shot mid-flow, uploads it with Upload Temporary Image to get a hosted source, and renders it into the campaign template alongside the recipient's name and offer. This is where Copicake's temporary storage needs to be understood rather than assumed: temporary uploads live for roughly a day, so the render has to happen in the same run, and the resulting permanent URL is the thing worth keeping. When an agent finds a saved campaign whose image source is a temporary URL from a previous run, it stops rather than shipping a set of assets with a broken image layer, and asks whether to regenerate the source or pull the last approved asset from storage.

Human-in-Loop Highlight

The gate on this connector sits on the QR layer, because that is the part of the asset that does something. An agent about to render two thousand event tickets renders exactly one first, stores it with Save Rendered Image, and posts it to the events channel: "Sample ticket for Dana Whitfield, tier General, code 8F2K-QM19. Scan this with the door app and confirm it opens Dana's registration. Approve to render the remaining 1,999, or hold." A code rendered from the wrong field looks perfect and fails at the door, and once tickets are emailed there is no recall. One person and one scan settle whether the mapping between the record and the code layer is right, and the agent renders the rest only after that answer comes back.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via email
Human decides
Agent resumes with decision

Agent Capabilities

4 actions

Rendering

2
  • Create Image Starts a render from one of your Copicake templates, replacing the named text, image, QR code, and shape elements with the values the agent supplies. The call returns immediately with a rendering id and the status processing, so it is the start of a render rather than the finished asset. Use it as the per-record production step once the template has been approved.
  • Get Rendering Retrieves a rendering by id to check whether the background render finished. While it runs the status is processing and the permanent URL is empty; on success the permanent URL holds the direct link to the image. Used to poll after Create Image, or to pick up a render whose id arrived from a Copicake webhook.

Files

2
  • Save Rendered Image Downloads a finished rendering and stores it in FlowRunner file storage, returning both the FlowRunner URL and the original Copicake URL. It waits for a render that is still processing, so it can follow Create Image directly. Used when the asset needs to outlive the vendor link, get attached to an email, or sit in an archive.
  • Upload Temporary Image Uploads an image to Copicake temporary storage and returns a hosted URL you can pass as the source of an image layer in Create Image. Temporary uploads are kept for roughly a day, so this is for images produced inside a flow rather than for permanent brand assets. Used when the picture that goes into the template did not exist before the run started.

Frequently Asked Questions

What can FlowRunner do with Copicake?

FlowRunner agents can run Create Image, Get Rendering, and Save Rendered Image in Copicake, plus 1 more action.

Does connecting Copicake to FlowRunner require OAuth?

No. Copicake connects to FlowRunner with an API key, no OAuth flow required.

Can Copicake trigger a FlowRunner workflow automatically?

Copicake doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Copicake

$100 in credits. No card required. Connect in minutes.