Pixel-perfect placeholders in minutes: “Integrating Lorem Picsum into Canva” with Andreas Braumann (Canva Austria GmbH.)

What this session set out to prove

Under the title “Integrating Lorem Picsum into Canva,” speaker Andreas Braumann from Canva Austria GmbH. built a small but useful content app live: a way to insert test images with exact pixel dimensions directly from within Canva’s search, optionally pre‑processed with blur and grayscale. The premise was simple and practical: you often need pixel‑perfect placeholders (say, exactly 100 × 100) for downstream tools, but stock integrations inside Canva generally filter by shape (square, portrait, landscape), not by exact width/height. The prototype flipped that constraint into a feature by letting the user type dimensions and parameters right into the search field and receiving only images in the correct size.

Throughout the talk, Braumann referred to the well‑known placeholder image service as “Lorem Picsum,” and in the implementation context he talked about picsum.photos/pixum.photos as the external image source. The app’s goal: support custom dimensions and two parameters—blur and grayscale—by passing them through to the external service so the images arrive pre‑processed.

The Canva developer model: content, editing, publish

Braumann opened with a quick tour of Canva’s developer platform. There are three types of extensions you can build:

• Content extensions: add content into Canva (the focus of the live coding).
• Editing extensions: modify existing content (examples he named were effects like grayscale or blur).
• Publish extensions: publish Canva‑created content out to a target platform.

One enticing reason to build here, he emphasized, is reach: “you can get your app in front of 20 million plus users.” The path is straightforward—code the app, upload it, Canva reviews it, and then it goes live. Instead of chasing distribution from scratch, you ride the platform’s existing user base.

Architecture and tooling: Glitch, Node.js, Express

For the demo, Braumann used Glitch to code in the browser. Glitch hosts a simple Node.js project with an Express server and redeploys instantly on save. No deployment pipeline, no CI—ideal for a live session. Canva explicitly recommends Glitch for development. For production, he cautioned, pick a different host: Glitch can be slow and will hibernate apps. But for prototyping and testing the developer contract, “it’s awesome.”

He started from Canva’s content extension template and added one critical piece missing from the boilerplate: request verification. The server validates that incoming calls are actually from Canva, using a secret set as an environment variable in Glitch. He also showed Glitch’s live logs—handy for debugging during the session.

The problem space: exact pixels, not just “square”

Canva’s stock integrations already bring rich content libraries, but they don’t expose strict pixel filters. If your workflow requires exact dimensions, you’re left to crop or resize later. Braumann’s brief was to change that experience via three features:

1. Enter custom dimensions directly into the app’s search (e.g., “100x100”).
2. Allow extra parameters, notably “blur” and “grayscale”.
3. Pass those parameters to the external image service so images arrive already blurred or in grayscale.

He also noted that the external source he used is independent—“not affiliated with Canva or Kaleido”—and that he hadn’t asked for permission in advance, given this was a test project.

The platform contract: POST in, resources out

The Canva template scaffolds the wiring for content apps. The key endpoint is a POST on “content resources find,” which the Canva platform calls to fetch items. The expected response is an array of resources (images, in this case).

In the default sample, the endpoint fetches a list of images from an external service and returns them as is. Braumann replaced that with logic to build images on demand according to the search input. A few important points he highlighted:

• The request body contains a query (the user’s search text) and a limit that suggests how many items to return. In his testing, this was consistently 20, though the app can technically respond with any count.
• The response structure needs to match the platform’s expectations: a type (e.g., “image”), plus id, name, a thumbnail URL, the actual URL, and a content type. In the demo, the content type was “image.jpg,” and for simplicity both URL fields were set to the same value.
• Canva expects stable identity. If a user drags an image into a design, the platform should be able to fetch the same asset again later. That led to a crucial implementation detail: seed‑based URLs.

Search syntax: parse dimensions and pass‑through parameters

The app treats the search box as a lightweight DSL for image requests:

• The format is “WIDTHxHEIGHT, optional parameters, separated by commas.” Example: “200x200, blur=3, grayscale”.
• Parsing steps: split the query on commas; take the first segment as dimensions and split it on “x” to extract width and height.
• Defaults: if the app is opened for the first time and no query is present, sensible default dimensions should be used so the results pane isn’t empty.
• Remaining parameters: instead of semantically validating them, the app passes them through as a raw query string (joined with “&”). That keeps the implementation lean as long as the target API accepts those parameters.

This yields three core values that drive the downstream request: width, height, and a “parameters” string holding things like “blur=3&grayscale”.

Limit and seeds: making randomness reproducible

Services like picsum.photos typically return random photos—great for variety, not so great for a platform that needs stable IDs. As Braumann put it, “you get random photos all the time,” but Canva needs an identifier that ensures a specific URL always maps to the same image. Enter seeds.

The implementation pattern is straightforward:

• Read the suggested number of items from the request body’s limit (often 20).
• Generate that many seeds (e.g., from random numbers). The external service doesn’t impose a strict seed format; what matters is that the same seed reproduces the same image.
• Create all resources in parallel for speed. In code, that meant mapping seeds to promises and awaiting them with Promise.all.

The seed doubles as the resource id in the response and as part of the URL, ensuring deterministic image selection.

Building the URL: seed, width, height, parameters

The heart of the integration is the URL assembly:

• Start with the external API endpoint (picsum.photos/pixum.photos). For determinism, use the “seed” endpoint.
• Append width and height as path segments—exactly as the user typed in the search.
• Attach the parameters string (e.g., “blur=3&grayscale”) so the service returns the image already blurred or in grayscale.

The resulting URL is used both for the thumbnail and the full image; the resource’s content type is “image.jpg.” For display, the app assigns a simple name format like “lorem pixum WIDTH x HEIGHT,” which is informative in the sidebar.

Verification and safety: accept only real platform calls

One notable enhancement Braumann added to the template was request verification. The server checks that requests are genuinely from the Canva platform and intended for this app. The mechanism relies on a secret stored in Glitch’s environment variables. If verification fails, the app refuses to respond, preventing misuse of the endpoint.

In his project, the verification lived in the lower portion of the Express server file—boilerplate, yes, but essential for trust.

Debugging live: logs, a typo, and instant feedback

Running live on Glitch provided immediate transparency. The logs made it obvious when an error occurred—in the session, a small typo broke the response until it was corrected. Because Glitch redeploys on save, fixes were a quick edit away. That reinforces the value of the tool for fast iteration.

Creating the Canva app: public vs team

Braumann concluded with a quick look at how to register an app in Canva: navigate to Developers → Integrations → Create an app. He stressed a non‑obvious detail: “This green is very special, because you can never change the selection you have here for this app.” In other words, choose carefully between a public app (reviewed by Canva) and a team app (for internal use). If you aim for public availability, plan for review.

End‑to‑end flow at a glance

From a runtime perspective, here’s the flow the prototype implements:

1. The user opens the content app in Canva.
2. Canva calls the app’s POST endpoint “content resources find,” passing a body with query and limit.
3. The app verifies the request (signature/secret) and parses the query:

• First segment: “WIDTHxHEIGHT” → width, height
• Remaining segments: join into a pass‑through parameter string
• If no query is present: apply default dimensions

1. The app generates seeds equal to limit and composes one deterministic image URL per seed (seed + width + height + parameters).
2. It builds resources in parallel (promises) and returns them with type=image, id=seed, a human‑readable name, a thumbnail URL, a URL, and a content type.
3. Canva displays the results; all images already match the intended size, with blur/grayscale applied if requested.

Editorial takeaways from the demo

• Text‑driven UX can move mountains: using the search field as a compact parameter interface avoids heavy UI and speeds up prototyping. The comma‑separated syntax (“WIDTHxHEIGHT, blur=…, grayscale”) is easy to remember.
• Respect the platform contract: the content‑app endpoint is a POST with a specific response shape. Deliver that faithfully and the Canva UI will do the rest.
• Seeds bridge randomness and stability: variety for the user, determinism for the platform. This is the kind of small detail that makes integrations reliable.
• Don’t skip verification: even in a demo, securing the endpoint matters. A single secret in environment variables goes a long way.
• Choose tools to fit the phase: Glitch shines in development; for production, migrate to a host that avoids hibernation and offers better performance.

Pragmatic choices and their trade‑offs

To hit the “15 minutes” target, the implementation made intentionally pragmatic calls:

• Parameters are passed through without semantic validation. Perfect for a prototype; in production, you’d likely validate and return helpful errors.
• Thumbnail and full‑size URLs are identical—fine for most workflows, but you could optimize by returning a smaller thumbnail.
• Defaults were mentioned but not deeply elaborated—shipping a sensible first view (e.g., 150 × 150) would make for a friendlier initial experience.

These choices underscore a healthy bias for end‑to‑end functionality first, followed by iterative hardening.

A practical checklist to replicate the approach

Engineers who want to try a similar integration can follow this high‑level sequence:

1. Create a Glitch project using a Canva content‑app template (Node.js/Express).
2. Add a secret as an environment variable and implement request verification so only Canva calls are served.
3. Implement the POST endpoint for “content resources find” that returns an array of image resources.
4. Read query from the request body, split on commas; parse the first segment as width/height; join the rest into a query‑string; apply defaults if missing.
5. Read limit; generate that many seeds.
6. For each seed, compose a deterministic image URL (seed, width, height, parameters) and build resource objects (type=image, id=seed, name, URLs, content type).
7. Build resources in parallel (promises) and return them collectively.
8. In Canva, create the app (“Create an app”) and decide between public or team—you can’t change that later.
9. Test in the Canva UI: type “WIDTHxHEIGHT, blur=…, grayscale,” drag images into a design, and verify behavior.

Closing thoughts: small app, sharp impact

“Integrating Lorem Picsum into Canva” demonstrated how a focused content extension can fill a real workflow gap: exact pixel sizes with simple processing, delivered right from the Canva search box. The idea is modest but impactful, and it leans on the platform where it matters: request verification, a predictable response contract, and seed‑driven determinism to make random images repeatable.

As a blueprint, the session shows how to get from idea to working prototype quickly: wire up the endpoint, parse a compact search syntax, compose deterministic URLs, and return well‑formed resources. Register the app, iterate on details, and you’ve got something useful in front of users—without building a whole ecosystem from scratch.

• 

  

  DALL·E 2: Image generation with visual AI

  David Estévez von kaleido spricht in seinem devjobs.at TechTalk über die Funktionsprinzipien von Visual AIs – und welche neuen Möglichkeiten immer leistungstärkere Tools mit sich bringen.

  Watch now
• 

  

  Visual AI Made Simple

  René Koller von kaleido erläutert in seinem devjobs.at TechTalk, wie das Devteam das Konzept von MVC auf MVVC erweitert hat und wie es zum Einsatz kommt.

  Watch now
• 

  

  Multiplatform Strategy for the remove.bg Apps

  Andreas Braumann von Kaleido untersucht in seinem devjobs.at TechTalk die Vor- und Nachteile von Flutter und wie man damit alle remove.bg Apps in einer einheitlichen Technologie haben könnte.

  Watch now
• 

  

  Software Engineering at kaleido.ai

  Riccardo Porrini von kaleido spricht in seinem devjobs.at TechTalk darüber, wie sich die Devteams während des Wachstums des Unternehmens organisiert haben.

  Watch now