Image Generation vs Placid: Visual Studio or Code-First API?

You Want to Generate Images, Not Design Them

You need to generate 10,000 personalized certificate images for a course platform. Or 500 product cards for a marketplace. Or dynamic OG images for every page on your site. The design is fixed — a background, some text, maybe a logo and a QR code. What changes is the data.

This should be a loop and an API call. Instead, you’re clicking around a visual editor, duplicating templates, and wondering how “programmatic image generation” turned into a design tool workflow.

Placid is a visual template editor with an API bolted on. You design templates in their browser-based studio — drag elements, set fonts, position layers — and then hit an API endpoint that fills in the dynamic fields. For a marketing team generating a handful of social cards a week, that works. For a developer building an automated pipeline that generates thousands of images from structured data, the visual editor becomes the bottleneck.

Templates as Platform State

Here’s the core problem with Placid’s approach: your templates live in Placid’s platform. They’re not files. They’re not exportable. They’re state stored in someone else’s database, editable only through their visual editor.

That means no version control. When a teammate changes the font size on your certificate template at 3 PM on a Friday, there’s no diff to review, no commit to revert, no history to audit. The template changed, and you find out when the output looks wrong.

No code review. Template changes bypass your entire development workflow. Pull requests, CI checks, staging environments — none of that applies to Placid templates. They live outside your codebase, governed by whoever has access to the Placid dashboard.

No programmatic creation. You can’t generate a template from code. Every template starts in the visual editor, which means a human has to click through the design process before the API can use it. If your use case requires dynamically composing templates based on input data — different layouts for different product categories, for example — you need to pre-create every variation by hand.

This isn’t a minor inconvenience. It’s a fundamental architectural constraint. Your image generation pipeline depends on state that exists outside your codebase, outside your deployment process, and outside your control.

The Credit Math

Placid’s entry tier costs $19 per month for 500 images. That’s $0.038 per image. The next tier is $49 for 2,000 images — $0.025 each. For teams generating high volumes, the per-image cost adds up fast, and you’re locked into monthly credit buckets that expire whether you use them or not.

If your use case is bursty — a course cohort graduates and you need 5,000 certificates in one afternoon — you either pre-purchase credits you won’t use most months, or you hit your limit and wait until the next billing cycle.

The pricing model assumes steady, predictable usage. Automated pipelines rarely work that way.

No HTML, No CSS, No Markdown

Placid templates support text, images, and basic shapes. But there’s no HTML or CSS rendering, which means you can’t use web technologies you already know to define complex layouts. And there’s no Markdown support in text layers, so formatting like bold, italic, or mixed styles within a single text block requires separate text elements positioned manually in the editor.

If you’ve ever tried to render a paragraph where one word is bold and the rest isn’t — in a tool that only supports plain text layers — you know the workaround: split it into three text elements and align them by hand. That’s fragile, tedious, and breaks the moment the text length changes.

Templates as Data

The Iteration Layer Image Generation API takes a different approach. Templates are JSON. A template is an array of layers — each layer is a typed object with explicit properties for position, size, color, font, and content. You construct them in code, send them in a request, and get an image back.

No visual editor. No platform state. No clicking.

Because templates are JSON, they inherit every tool in your development workflow for free:

• Version control. Templates are code. They live in your repo, tracked by Git, with full history.
• Code review. Template changes go through pull requests like everything else.
• Dynamic composition. Generate templates programmatically based on input data. Different layouts for different product types, different locales, different user segments — all logic, no manual work.
• Testing. Assert on template structure in your test suite. Catch regressions before they ship.

This is the difference between a design tool and a developer tool. Placid assumes someone will design each template. Iteration Layer assumes someone will write each template — or, more likely, write the code that generates templates.

What the API Supports

The layer system covers the building blocks of programmatic image composition:

• Solid-color backgrounds and gradients for base layers
• Rectangles with opacity and angled edges — for cards, frames, badges
• Text layers with 98 bundled fonts, Markdown support (bold, italic, mixed formatting in a single layer), horizontal and vertical alignment, and auto-scaling text that fits its bounding box
• Static images from URLs or base64 — logos, headshots, product photos
• Image overlays with AI-powered smart crop and background removal built into the layer
• QR codes with configurable foreground and background colors
• Barcodes in 6 formats — Code128, Code39, EAN-13, EAN-8, Codabar, ITF

Every layer has pixel-precise positioning. You define x, y, width, and height in pixels. No percentage-based guessing, no responsive breakpoints — you’re generating a fixed-dimension image, and every element goes exactly where you put it.

A Certificate in Code

Here’s a complete example — a course completion certificate with a verification QR code:

import { IterationLayer } from "iterationlayer";

const client = new IterationLayer({ apiKey: "YOUR_API_KEY" });

const result = await client.generate({
  width_in_px: 1056,
  height_in_px: 816,
  format: "png",
  layers: [
    { type: "solid-color-background", color: "#fefce8" },
    { type: "rectangle", x_in_px: 20, y_in_px: 20,
      width_in_px: 1016, height_in_px: 776, color: "#ffffff" },
    { type: "text", text: "Certificate of Completion",
      x_in_px: 100, y_in_px: 80, width_in_px: 856, height_in_px: 60,
      font_family: "Playfair Display", font_size_in_px: 36, color: "#1c1917",
      horizontal_alignment: "center" },
    { type: "text", text: "**Jane Doe**",
      x_in_px: 100, y_in_px: 300, width_in_px: 856, height_in_px: 50,
      font_family: "Inter", font_size_in_px: 32, color: "#1c1917",
      horizontal_alignment: "center" },
    { type: "qr-code", value: "https://verify.example.com/cert/abc123",
      x_in_px: 428, y_in_px: 600, width_in_px: 120, height_in_px: 120,
      fg_hex_color: "#1c1917", bg_hex_color: "#ffffff" },
  ],
});

That’s a warm-toned certificate with a white card, a serif title, the recipient’s name in bold (via Markdown), and a verification QR code at the bottom. Five layers, one API call.

Now imagine wrapping this in a function that takes a name and a verification URL. You’ve got a certificate generator. Feed it a CSV of 5,000 graduates and you’re done before lunch — no template editor, no manual exports, no credit bucket anxiety.

The same pattern applies to any use case where the layout is fixed but the data changes: product cards, event badges, social cards, shipping labels, ID cards, report covers.

Dynamic Composition

Because templates are just arrays of layer objects, you can compose them with code. This is where the JSON-based approach pulls away from visual editors entirely.

Need a product card that shows a “Sale” badge only when the item is discounted? Add a conditional rectangle and text layer. Need a different background color per product category? Map category to hex code. Need to support 12 languages with different text lengths? Auto-scaling text handles it — the font size adjusts to fit the bounding box.

None of this requires creating template variants in a visual editor. It’s logic. It lives in your codebase, next to the rest of your business rules.

Side-by-Side

When Placid Makes Sense

Placid is built for marketing teams who think in terms of design, not code. If your workflow is “a designer creates a template, a marketer fills in the fields through a dashboard, and the output goes to social media” — Placid fits that. The visual editor is the product, and the API is a convenience layer on top.

But if templates are part of your application logic. If they need to change when your code changes. If you need to generate thousands of images from structured data without a human touching a GUI. If you want your image generation pipeline to be as testable, reviewable, and deployable as the rest of your code. Then you need templates that are data, not platform state.

Get Started

Check the docs for the full layer reference, font list, and SDK guides. The TypeScript and Python SDKs handle authentication and response parsing — your first generated image is a few lines of code away.

Image Generation is one API in a composable suite — chain it with Document Extraction to turn parsed data into visual assets, or with Image Transformation to post-process the output. Same auth, same credit pool.

Sign up for a free account at iterationlayer.com/image-generation — no credit card required.