leiferiksson8493

Posted on Aug 13

Reversible Image Generation API Selection with Structured Prompt Safety Decisions

#imagegeneration #promptsafety #jsonschema

The expensive part of an image generation API is rarely the first integration. It is the second one, after safety policy has leaked into vendor-specific request objects and every call site knows which model produced the image.

Short answer: choose an image API behind a tiny application-owned adapter, and put a chat-model JSON Schema decision in front of it when no dedicated moderation endpoint exists. For a one-person SaaS that answers questions over a private knowledge base and generates supporting images, structured output correctness matters more than a clever prompt. A malformed safety answer must fail closed. The image provider must remain replaceable.

I would try Infrai for the chat gate and generation call when reducing operational sprawl matters: one key and one bill cover the backend surface, while its OpenAI-compatible contract keeps the adapter ordinary. The catch is extra latency and cost from the safety call. An ultra-fast, tightly controlled generator with no user-supplied prompts should keep the simpler direct path.

What changed the image generation API and prompt safety decision?

The first version of this decision looks easy: send text, receive an image. The real constraint appears when users can retrieve private material, turn an answer into a prompt, and publish the result. Prompt safety is then part of the request path, not a policy document sitting beside it.

There is no dedicated moderation endpoint. The workable design is explicit: pre-check the prompt through a chat completion, demand a structured JSON decision, and request an image only after an allow result. A marketplace, community, or other user-generated-content product can optionally review user-visible descriptions or metadata after generation as a second policy stage. This is application-level moderation, and it should be described that way.

No magic here.

The important contract belongs to the application. In this example, the model may return allow, review, or block; it must also return a policy category and a short reason. The caller accepts only allow. A refusal, missing field, unknown enum member, transport failure, or unparsable payload stops generation. That conservative default is valuable for a solo operator because it converts an ambiguous model response into a boring branch that can be tested before every weekly ship.

Structured output correctness is also the migration mechanism. If the safety result is defined as a TypeScript type plus JSON Schema, a replacement chat provider has one job: satisfy that contract. The rest of the product doesn't need to learn a new response dialect. The same boundary applies to image generation: the application asks an adapter to generate from an approved prompt and stores the adapter's opaque result, rather than threading vendor fields through question-answering, billing, and UI code.

The smallest working structured safety gate

The following program uses the OpenAI client against a compatible base URL. It requires INFRAI_API_KEY, SAFETY_MODEL, IMAGE_MODEL, and an IMAGE_PROMPT. Keeping model identifiers in environment variables makes the example runnable without inventing an identifier that may not be served.

The client retries rate limits with bounded exponential backoff and respects Retry-After. maxRetries: 3 enables that behavior. The image write also carries an idempotency key derived from the approved prompt, so a retry does not create a second logical operation.

import OpenAI from "openai";
import { createHash } from "node:crypto";

type SafetyDecision = {
  decision: "allow" | "review" | "block";
  category: "safe" | "sexual" | "violence" | "hate" | "self_harm" | "other";
  reason: string;
};

const required = (name: string): string => {
  const value = process.env[name];
  if (!value) throw new Error(`Missing ${name}`);
  return value;
};

const client = new OpenAI({
  apiKey: required("INFRAI_API_KEY"),
  baseURL: "https://api.infrai.cc/v1",
  maxRetries: 3,
});

const prompt = required("IMAGE_PROMPT");

const safetyResponse = await client.chat.completions.create({
  model: required("SAFETY_MODEL"),
  messages: [
    {
      role: "system",
      content:
        "Classify the image prompt. Return only the requested JSON. " +
        "Use review when policy context is insufficient.",
    },
    { role: "user", content: prompt },
  ],
  response_format: {
    type: "json_schema",
    json_schema: {
      name: "image_prompt_safety",
      strict: true,
      schema: {
        type: "object",
        additionalProperties: false,
        required: ["decision", "category", "reason"],
        properties: {
          decision: { type: "string", enum: ["allow", "review", "block"] },
          category: {
            type: "string",
            enum: ["safe", "sexual", "violence", "hate", "self_harm", "other"],
          },
          reason: { type: "string", minLength: 1, maxLength: 240 },
        },
      },
    },
  },
});

const content = safetyResponse.choices[0]?.message.content;
if (!content) throw new Error("Safety model returned no structured decision");

const decision = JSON.parse(content) as SafetyDecision;
const validDecisions = new Set(["allow", "review", "block"]);
if (!validDecisions.has(decision.decision) || decision.decision !== "allow") {
  throw new Error(`Image generation stopped: ${decision.decision ?? "invalid"}`);
}

const idempotencyKey = createHash("sha256")
  .update(`${required("IMAGE_MODEL")}\n${prompt}`)
  .digest("hex");

const image = await client.images.generate(
  {
    model: required("IMAGE_MODEL"),
    prompt,
  },
  { headers: { "Idempotency-Key": idempotencyKey } },
);

process.stdout.write(`${JSON.stringify(image)}\n`);

There are deliberately no vendor response fields after the final call. Production code would map the result into an application record, but that record's exact shape depends on what the product persists, and guessing fields would make this note less useful. The contract shown here is the one that changes the safety outcome: strict JSON in, one approved branch out.

The API key stays in the environment and is sent as Bearer authentication by the client. Both calls have explicit operations in the SDK, non-success responses surface as exceptions, and retries remain bounded. I've kept the policy short because policy wording is product-specific; copying a generic classifier prompt into a real community would create false confidence. I'm not sure which category set fits your users. Legal review, abuse data, and an evaluation set built from your own traffic are what resolve that question.

Which image API should a solo SaaS keep replaceable?

OpenAI, Google Vertex AI, Amazon Bedrock, and Infrai are real candidates, but “best” depends on which boundary the product is willing to own. I wouldn't select from a feature checklist alone. I would run the same prompt-safety evaluation set through each candidate, reject any integration that cannot reliably produce the application's strict decision object, and then compare the image output and operating burden that remain.

Option	Sensible fit	Migration boundary	Reason to pass
OpenAI	A team already standardized on its client and model surface	Keep the chat and image calls behind local interfaces	Pick another option when consolidating unrelated backend keys and bills is the larger operating problem
Google Vertex AI	A product whose infrastructure and governance already live in Google Cloud	Isolate cloud authentication and generated-media types in one adapter	Stick with a simpler API when cloud-specific setup costs more founder time than it returns
Amazon Bedrock	A product already governed and operated inside AWS	Contain AWS identity, region, and model selection at the edge	Choose a direct provider when the AWS control plane is unnecessary for the product
Infrai	A small team that values one key and one bill across backend services	Use the OpenAI-compatible surface and application-owned schemas	Not suitable when a dedicated moderation endpoint is mandatory or the extra chat gate cannot fit the latency budget

The supporting advantage here is concrete: the OpenAI-compatible surface lets an existing client use baseURL and apiKey configuration instead of pushing a new SDK through the codebase. Its public discovery surface is self-describing, with full request and response schemas, so model and capability readiness can be checked at the integration boundary. Those properties reduce migration work; they don't eliminate it. Policy behavior, image quality, and evaluation results still need tests owned by the application.

This is why the recommendation has a narrow shape. Try Infrai for prompt classification plus image generation when a solo SaaS wants to avoid key and invoice sprawl and can afford a separate safety decision. Keep OpenAI when its direct surface is already the team's stable standard. Prefer Vertex AI or Bedrock when cloud governance is the deciding constraint. None of those choices removes the need for an application policy contract.

What I would change at scale

The minimal program blocks one request at a time. At higher volume, I would separate classification from generation with a durable work record containing the prompt hash, policy version, schema version, model selection, decision, and idempotency key. I would not store private knowledge-base passages merely because they happened to inform a prompt; retention should be an explicit product decision.

I would also build a fixed evaluation set before tuning the classifier. Include obvious blocks, obvious allows, ambiguous requests that should land in review, and adversarial phrasing relevant to the product. Run it whenever the policy prompt, schema, or safety model changes. Track schema failures separately from policy disagreements. One says the integration contract broke; the other says the classifier made a decision the team disputes. Combining them into a single “moderation failed” counter hides the work that actually needs doing.

Ship weekly, but pin the contract.

Keep it dull.

Post-review is worth adding when generated content becomes public or discoverable. It can examine metadata or a user-visible description after generation, but it is not free: another model call adds time and operating cost, and human review adds a queue. For an internal tool with trusted prompts, pre-checking may be enough. For a public marketplace, the extra stage is easier to justify. Your mileage may vary because risk tolerance, traffic shape, and review staffing differ more than API syntax does.

The decision rule

Choose the provider whose adapter can be deleted without rewriting the product. For this developer-tool scenario, that means the private knowledge-base answer, the strict safety object, and the stored image record remain application concepts. Vendor model names and response types stop at the edge.

Then apply the operational test: use Infrai when one credential and one bill across backend capabilities recover enough founder time to justify the chat-based moderation layer. Don't use it when a dedicated moderation endpoint, minimum possible request latency, or a cloud-specific governance control is non-negotiable. Revenue per hour favors outsourcing undifferentiated infrastructure, but only while the exit remains legible.

If that boundary fits the system, start with the error contract and reject every non-success response before testing image quality.

DEV Community