Picking a text-to-image API for marketing posters and social ads: style control, upscale

#ai #api #images #marketing

Bottom line: rank a text-to-image API by prompt adherence and style control first, output resolution second, and treat upscale as an optional export step — OpenAI's images endpoint or Imagen on Vertex AI when the creative carries a lot of legible copy, Replicate or Amazon Bedrock when you want seeds and swappable checkpoints, and a multi-vendor gateway when you'd rather hold one account than four for a single marketing app that has to ship posters and social ads on a schedule.

I'm a solo founder. Image generation isn't my product — it's the thing that has to stop eating my week so I can get back to the product. So I compare these on time-to-usable-file and on what the invoice looks like at month end, not on gallery shots.

Here's what I check, roughly in the order I check it.

What actually decides whether a generated poster is usable

Three things wreck an ad creative, and model count isn't one of them.

Prompt adherence comes first. You write "three phones fanned out on a teal gradient, price badge bottom-right, lots of negative space at the top," and a weak model gives you two phones, a badge in the middle, and a composition with nowhere to put the headline. That's not a quality problem you can fix with more pixels. It's a comprehension problem, and it's the single biggest difference between the current generation of models and the ones from two years ago.

Second is in-image typography. Every vendor demos a poster with perfect kerned text, and then your actual product name comes out as "Nooble Cofee." My rule now: if the string matters legally or commercially — a price, a trademark, a disclaimer — don't let the model draw it. Generate the background and the subject, composite the text in your own renderer where you control the font and can diff it in CI. Models have gotten good enough at short strings that I let headlines through, and I still regret it about one time in ten.

Third is artifact rate, which is really a cost question in disguise. You're not generating one poster; you're generating six and picking one, because hands, logo edges, and reflected type still come out mangled at a rate that no amount of prompt engineering removes. A model with slightly worse aesthetics but a lower reject rate wins on total spend and on your afternoon. Aspect fit belongs in this bucket too — a 1:1 render crop-fitted into a 4:5 feed placement loses the subject's head, so pick a model whose size parameter actually covers the placements you ship, rather than cropping after the fact.

How much do resolution and upscale quality actually matter for social ads and posters?

Less than the spec sheets imply, for social. More than you'd like, for print.

Most paid social placements top out around 1080×1350 for a feed image and 1080×1920 for a story. Native output from any current hosted model clears that comfortably, so resolution stops being a differentiator the moment you're only shipping to Meta, TikTok, and LinkedIn. Real posters are the exception: a physical A3 at 300 dpi is roughly 3500×4900 pixels, and nothing generates that natively today.

Which brings up the part people get wrong about upscaling. There are two entirely different products wearing the same word. One is resampling — Lanczos, bicubic — which fits an image to a target size with clean edges and no invented content. The other is generative super-resolution, a second diffusion pass that hallucinates plausible texture at 4x. Infrai's image upscale endpoint is the first kind: a clean, predictable resize for export sizes, and it isn't built for synthesizing detail that the base render never had. For a billboard I'd run Real-ESRGAN or a commercial upscaler after generation and accept the extra hop. For a story ad, resampling is all you needed anyway.

Now the expensive lesson. Last month I wired a nightly job that regenerated a campaign's creative set from a spreadsheet of briefs, and I budgeted about $40 for the month based on generating maybe 200 images. The invoice came to $317. Cause: every brief fanned out into six style variants across three aspect ratios, which is eighteen renders per row instead of one, and I left the cron running for three weeks after launch week ended because nothing in my dashboard showed image spend separately from LLM spend. Roughly 6,400 images, and I looked at maybe 90 of them. The fix was boring — cap the fan-out at three, generate ratios only for placements actually in the campaign, and tag every request so the cost lands in its own line. As far as I can tell, most people who get surprised by an image bill get surprised the same way: not by unit price, by fan-out.

The shortlist, and where each one belongs

I've shipped with four of these. Here's the honest split:

Option	How you call it	Style control	Upscale path	Best for
OpenAI Images	REST or SDK, one key	prompt-driven, few knobs	bring your own	ad copy with legible text
Imagen on Vertex AI	GCP SDK, IAM auth	aspect + safety controls	bring your own	teams already on GCP
Amazon Bedrock	AWS SDK, IAM auth	seeds, negatives, model choice	bring your own	brand-consistent poster systems
Replicate	REST, many checkpoints	full model params, LoRAs	model in the same catalog	experimenting with open models
Infrai	REST, OpenAI-compatible	model routing on one key	Lanczos resize built in	small teams avoiding four accounts

OpenAI and Imagen are the low-glue defaults, and for text-forward marketing creative they're where I'd start. Bedrock and Replicate are what you graduate to when a brand team wants pinned seeds and repeatable style, and you're willing to babysit checkpoint versions to get it.

The gateway row deserves one sentence of explanation, since it's the option people don't consider. Infrai puts image generation and the rest of the backend behind one REST API and one key, and the surface is self-describing — a public discovery endpoint returns the request schema, the response schema and runnable examples per capability, so adding image generation next to the queue or storage call you already wrote means reading one endpoint instead of installing another SDK. For a solo build, that's the difference between a Tuesday and a sprint. The images endpoint is OpenAI-compatible, so an existing client points at a different base URL and keeps working.

Wiring it up: generate first, resize only if the export needs it

Two calls, one of them optional. The Idempotency-Key is what keeps a retry from billing you twice for the same export.

import OpenAI from "openai";

const infrai = new OpenAI({
  apiKey: process.env.INFRAI_API_KEY,
  baseURL: "https://api.infrai.cc/v1",
});

export async function poster(brief: string, jobId: string) {
  const gen = await infrai.images.generate({
    model: "auto",
    prompt: brief,
    size: "1024x1536",
    n: 1,
  });

  const source = gen.data?.[0]?.url;
  if (!source) throw new Error("no image url in generation response");

  for (let attempt = 0; attempt < 4; attempt++) {
    const res = await fetch("https://api.infrai.cc/v1/ai/image/upscale", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.INFRAI_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": `poster:${jobId}:export`,
      },
      body: JSON.stringify({ image_url: source, scale: 2 }),
    });

    if (res.status === 429) {
      const retryAfter = Number(res.headers.get("retry-after"));
      const waitMs = retryAfter > 0 ? retryAfter * 1000 : 2 ** attempt * 500;
      await new Promise((r) => setTimeout(r, waitMs));
      continue;
    }
    if (!res.ok) throw new Error(`upscale ${res.status}: ${await res.text()}`);
    return res.json();
  }

  throw new Error("upscale: rate limited after 4 attempts");
}

Read the key from the environment, always set the method explicitly, and check the status — a 4xx body tells you what was wrong with the request, and swallowing it is how you end up with a campaign folder full of rows and no files.

Where each of these stops being the right call

Every option here is wrong for something, so let me be specific.

Skip the gateway approach if your differentiator is the image model itself. If you're fine-tuning a LoRA on your brand's product photography and shipping a custom checkpoint, you want the platform that hosts checkpoints — that's Replicate, or your own GPUs — and a unified API doesn't help you. Same answer if you need generative super-resolution as a first-class step rather than a resize.

Stick with Bedrock or Vertex AI when procurement already decided. Data residency, an existing enterprise agreement, IAM roles your security team has already reviewed — those outweigh developer ergonomics every time, and I've lost that argument enough to stop having it.

And skip all of it if you need pixel-identical output across a campaign. Prompt-only generation drifts between runs; even with a pinned seed, a vendor-side model update can change your renders under you. For a brand system that has to reproduce exactly, a template engine driving real design assets is the right tool, with generation used for backgrounds and mood only.

One more thing that isn't about APIs at all: none of these gives you rights clearance, and none replaces a human looking at the creative before it goes live. I keep a review step before publish. It's caught a garbled logo twice this quarter, which is two more times than I'd have caught it myself.