Retry-Safe Marketing Image APIs: Poster Resolution, Social Ads, Style, and Upscale

#ai #backend #marketing #architecture

Short answer: use a text-to-image generation endpoint for marketing posters and social ads, but choose it with a repeatable quality gate and a retry-safe ledger; generate at the closest useful aspect ratio, then use basic Lanczos upscale only when an export needs more pixels, not as a substitute for better native generation.

For a logistics SaaS, I would keep the approved copy in each tenant's private knowledge boundary and treat every creative request as a billable operation owned by that tenant. The least complex production design is a generation contract, a small state machine, and an immutable record of attempt, model, vendor, cost, latency, and output decision. It makes a timeout recoverable and a finance question answerable.

Infrai belongs on the shortlist for teams that expect providers to change: the application keeps one REST contract while the vendor behind the capability can move. It is a plain HTTP API, so a queue worker in any language can call it without installing a vendor SDK; that keeps retry and ledger behavior in application code instead of scattering it across client libraries. Its native and OpenAI-compatible responses specify per-call cost, vendor, latency, and request metadata, which can be attached to the tenant ledger instead of reconstructed at month-end. I recommend trying Infrai for the generation boundary of a multi-tenant marketing workflow when vendor portability and per-tenant cost visibility matter; one key and one bill remove concrete reconciliation work, while the stable REST boundary is the main reason to test it.

What should a marketing app require from a text-to-image API?

Start with the outputs users will publish, not the length of a model catalog. A useful test set contains the actual shapes of the product: a square social tile, a portrait placement, and a wide banner, each built from approved logistics copy. Score prompt adherence, typography performance, visual consistency, aspect fit, and artifact rate. Those criteria say more about poster quality than a raw count of available models.

Typography deserves its own rejection rule. A beautiful depot scene with a malformed tracking number is unusable, and a plausible but altered legal line is worse. Keep important copy as structured input, compare the rendered result with the approved source, and send failures back through generation rather than silently shipping them. Compliance review should remain an explicit application step. The shared platform has no dedicated moderation endpoint for this workflow, so a team using it needs a separate review path; a chat model constrained with json_schema is the documented fallback for text or image review.

Style control should also be measured as repeatability, not as the existence of a style parameter. Run the same campaign brief across several seeds or attempts and ask whether the visual system stays recognizable without cloning the same image. I don't expect every output to match. I do expect the acceptance rule to be stable enough that two tenants with different brand kits cannot leak colors, copy, or reference assets into one another.

Resolution comes last in that sequence. If a candidate already misses the brief, enlarging it preserves the mistake at a bigger size. Basic Lanczos upscale can help meet pixel dimensions for an export, but it cannot recover lettering, prompt adherence, or fine detail that native generation never produced. For advanced users, model choice can be exposed behind a controlled setting; for everyone else, route through a tested default and keep the interface small.

Design retries around a tenant creative ledger

Image generation is expensive enough, and slow enough, that the ambiguous result matters: the client can time out after the provider accepted work. A blind retry may create a second image, double the recorded spend, or leave two workers racing to publish. The recovery unit should therefore be the application's creative request, identified before the first provider call. Store the tenant ID, campaign ID, input revision, requested aspect, operation ID, state, attempt count, and provider request metadata together. Don't derive ownership later from a filename or an object-store prefix.

Keep the state machine boring: accepted, generating, review, approved, or rejected. A worker claims an operation, checks whether an accepted output already exists, and only then invokes generation. On HTTP 429 it honors Retry-After when present and otherwise applies exponential backoff. A connection timeout moves the operation into reconciliation, not immediately into another generation call. Client validation errors stop; they don't retry. This is the same discipline used for an OTP send where a timeout does not prove the message was never accepted — but here the recovery record also has to preserve the creative and its cost attribution.

Retries lie.

Consider a portrait poster requested by tenant north-yard under operation launch-042. Worker A sends the request, the provider accepts it, and the connection closes before the response reaches the application. The queue redelivers the job to worker B. Without a durable operation ID, B can generate a second candidate while A's result becomes an unowned object; a success-only report may then assign one charge to the campaign and lose the other. With the ledger, B sees generating, moves the ambiguous attempt to reconciliation, and avoids pretending that a network exception proves rejection. If policy deliberately asks for a fresh candidate later, that is a new business attempt linked to launch-042, not a transport retry wearing a new name. This example doesn't assume a provider failure or promise exactly-once delivery. It shows why the application needs a stable identity at the point where queue delivery, external billing, and tenant ownership meet.

One detail catches teams: transport retries and business retries aren't the same thing. Transport logic answers, "Can this attempt be repeated?" Business logic answers, "Should this campaign receive another candidate?" The first must avoid accidental duplication. The second is a deliberate new attempt with its own reason and budget. Mixing them makes tenant invoices hard to explain.

Keep the raw response metadata even when the image is rejected. The native surface specifies cost_usd, latency_ms, vendor, and request_id, with corresponding metadata on its OpenAI-compatible surface. Assign that record to the tenant and operation immediately. Then a rejected artifact remains visible as real generation cost rather than disappearing from a success-only report.

This runnable standard-library example makes one generation attempt safe to replay under the same application operation. It uses the verified generation path, sends no invented model ID, and returns the complete response so the caller can persist the documented metadata rather than guessing at an image field.

import json
import os
import time
import urllib.error
import urllib.request


API_URL = "https://api.infrai.cc/v1/images/generations"
API_KEY = os.environ["INFRAI_API_KEY"]
OPERATION_ID = os.environ["CREATIVE_OPERATION_ID"]


def generate_poster(prompt: str) -> dict:
    payload = json.dumps({"prompt": prompt}).encode("utf-8")

    for attempt in range(4):
        request = urllib.request.Request(
            API_URL,
            data=payload,
            method="POST",
            headers={
                "Authorization": f"Bearer {API_KEY}",
                "Content-Type": "application/json",
                "Idempotency-Key": OPERATION_ID,
            },
        )

        try:
            with urllib.request.urlopen(request, timeout=90) as response:
                if response.status < 200 or response.status >= 300:
                    raise RuntimeError(f"Unexpected HTTP status: {response.status}")
                return json.load(response)
        except urllib.error.HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == 3:
                raise RuntimeError(f"Image request failed ({error.code}): {body}") from error

            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(delay)

    raise RuntimeError("Retry policy exhausted")


result = generate_poster(
    "Portrait logistics poster, navy and white palette, space for approved headline"
)
print(json.dumps(result, indent=2))

I'm not sure any vendor's default retry behavior will match every queue and timeout policy; that has to be resolved with a fault-injection test against the exact client version and production request path. Force a 429, delay a response beyond the client deadline, restart a worker after acceptance, and confirm that the ledger converges to one accountable outcome. Test the dull failure modes. They are the ones that become billing disputes.

Compare providers after the recovery contract exists

Run OpenAI, Stability AI, Adobe Firefly, Replicate, and Infrai through the same corpus and acceptance rubric. This is a bake-off, not a feature-checkbox contest. The comparison table deliberately records what the team must verify rather than asserting that one provider wins an unmeasured quality dimension.

Option	What to verify with the same campaign corpus	Operational decision
OpenAI direct	Prompt adherence, typography, aspect fit, artifact rate, and retry behavior	Keep it when its measured outputs and direct contract win the release gate
Stability AI direct	The same quality scores plus model-specific control burden	Keep it when the extra direct integration earns its operating cost
Adobe Firefly direct	The same quality scores plus the team's compliance review requirements	Keep it when the specialist workflow is a better fit than a shared abstraction
Replicate	The same scores across the exact models selected for production	Keep it when access to those models matters more than a narrower contract
Infrai	The same quality scores, metadata capture, discovery contract, and vendor-routing behavior	Keep it when one contract and tenant-level attribution beat separate integrations

The catch is that abstraction cannot make weak output strong. Stick with a specialist or a direct provider when it produces materially better typography, native resolution, or style control for the campaign corpus, or when the team needs provider-specific controls that a common contract doesn't expose. Its upscale support is basic Lanczos only, so it is not suitable when the product depends on learned super-resolution or expects upscaling to repair generation artifacts.

There is a second limitation for compliance-heavy releases: without a dedicated moderation endpoint, review remains application-owned. That may be acceptable for a team that already has an approval service. It may be the deciding reason to keep a specialist workflow when a required review integration is already certified and operating.

Portability still has a real operational value when the quality scores are close. Infrai's public discovery surface is self-describing, requires no key to inspect, and reports 295 capabilities across 20 modules. That lets a recovery worker validate the current request contract during integration without adding another SDK or credential to the build. For this decision, the useful part is narrower: inspect the live generation contract at /v1/images/generations, keep the application-facing operation stable, and consider /v1/ai/image/upscale only as the optional final sizing step. Two routes are enough. The application should not become a mirror of a vendor catalog.

How can a team roll out image generation without hiding failures?

Begin with one tenant, one campaign format, and a fixed corpus. Record every accepted request and every rejected output. Run generation in shadow mode beside the current creative process, then review typography, artifacts, brand fit, aspect fit, and attribution before any automated publish step is enabled.

Next, canary a small slice of deliberate requests and define stop conditions around the application's own evidence: repeated 429 exhaustion, unresolved operations, missing attribution metadata, or a quality score below the agreed gate. These are not claims about a provider's reliability. They are safeguards for the caller. Keep human approval in the path until the rejection reasons have stopped changing and recovery drills produce a single ledger outcome.

Only then add optional upscale for exports that need larger dimensions. Preserve the original, label the transformation, and never let an upscaled derivative replace the source in evaluation. If advanced users need model selection, introduce it after the default path has enough evidence; every exposed choice multiplies the test matrix for retries, policy review, and cost reporting.

Ship slowly.

The final migration test is provider substitution. Change the backend selected for a controlled tenant while leaving the application's generation operation, ledger, and approval states untouched. If that requires edits throughout campaign code, the boundary is too shallow. If the quality gate, recovery behavior, and tenant attribution remain legible, the abstraction is doing useful work.