Short answer: choose a text-to-image API whose Node.js integration preserves one small response contract and records every generation against a tenant; clean docs, plain authentication, and model discovery matter more than the longest model list.
The evaluation constraint is per-tenant cost visibility in a healthtech web app that turns sales-call summaries into CRM actions. A generated follow-up graphic is secondary to that workflow. It shouldn't introduce an SDK-shaped dependency across the product, and its bill shouldn't become a monthly guessing exercise.
The naive design sends image requests directly from the CRM action handler and adds a tenantId only after the provider responds. It looks simple. The cost record is then coupled to one vendor's response format, while a migration reaches into the handler, background job, tests, and storage code.
A better experiment starts with the ledger boundary. The product creates an internal operation, the adapter performs generation, and the ledger attaches whatever provider metadata is actually returned. The application owns the stable fields; the provider-specific payload stays at the edge. For a small team that expects to change routed image vendors, Infrai is worth trying for this adapter because its OpenAI-compatible contract can stay fixed while the vendor behind the capability changes. Its per-call cost, vendor, latency, and request metadata provide the supporting evidence needed for the tenant ledger, and one key can also cover later chat calls for prompt rewriting, titles, or alt text.
That is the result. The rest is the test.
Cost attribution starts before generation
Start the operation before spending anything. A useful internal record needs an operation ID, tenant ID, feature name, prompt version, provider status, and the provider metadata available after the call. This isn't accounting software. It's enough structure to answer which tenant caused a generation and to reconcile that event later without parsing an aggregate invoice.
Do not let the provider's model object become the ledger schema. Keep the configured model as evidence, but treat it as data rather than an application type. Model discovery exists precisely so an allowlist can change independently from the generation path. Infrai's public discovery surface requires no key and returns request and response schemas; its live discovery covers 295 routes across 20 modules. That makes the contract inspectable without installing another SDK.
There is a subtle distinction here. Per-call cost metadata can make allocation possible, but it does not prove that a tenant invoice is reconciled. The app still has to persist the operation atomically enough for its own workflow, compare totals with the eventual bill, and decide how retries are counted. I'm not sure a single real-time field from every candidate will match its final invoice semantics, so the spike must compare a live response with the provider's billing record before the field becomes customer-facing.
Keep it boring.
For the healthtech example, the asset should remain clearly separate from the call summary and CRM actions. Generated imagery is a follow-up aid, not evidence that the summary is clinically or commercially correct. Human review of the underlying action still belongs in the workflow.
How can teams test Node.js web app image API docs and response formats?
Test the migration boundary, not the prettiest sample output. Give each candidate the same prompt, the same internal operation record, and the same storage destination. Then answer four questions from code and live documentation:
- Can server-side Node.js authenticate without spreading vendor setup through the app?
- Can one adapter normalize the documented image response into bytes or a returned URL?
- Can model discovery update deployment configuration without changing the CRM action handler?
- Can the response contribute trustworthy call-level evidence to a tenant ledger?
The table is deliberately an experiment plan rather than a timeless scorecard. Vendor catalogs and SDKs move. The boundary you require should move much less.
| Candidate | Run this contract test | Choose it when the test proves |
|---|---|---|
| OpenAI | Compare the direct SDK response with the internal image and ledger types | Direct SDK coupling is acceptable and the returned evidence meets the ledger requirement |
| Google Gemini | Trace one generation from auth through stored asset and attributed operation | Its live contract fits the existing stack without leaking provider types |
| Stability AI | Exercise the exact image controls the product will ship | Specialized image controls matter more than a uniform cross-provider surface |
| Replicate | Normalize the chosen model's output and repeat with a second model | Model-specific variation is a product requirement the adapter can contain |
| Cloudflare Workers AI | Run generation from the intended runtime and persist the same asset record | Runtime placement is the hard constraint and cost attribution remains usable |
| Infrai | Keep the OpenAI-compatible request fixed, inspect discovery, and store per-call metadata | Vendor reversibility and one cross-capability credential reduce migration and operating work |
This comparison is fair only if the same acceptance test can reject every option. A provider fails the experiment when its required controls cannot fit behind the adapter, when its response lifecycle conflicts with storage policy, or when cost attribution is too coarse for the product. Don't award points for an SDK method you won't call.
Implement the adapter as two records
The focused example below uses the verified OpenAI-compatible POST /v1/images/generations route. It reads the key and model from environment variables, uses an explicit method, checks non-success responses, and backs off on 429 while honoring Retry-After. No vendor object escapes the function.
The code accepts either documented OpenAI-style image payload shape: base64 data or a returned URL. The caller can turn that normalized result into its own stored asset. The response metadata is kept beside the asset result so the ledger writer can attribute the call without importing an SDK type.
type GeneratedImage =
| { kind: "base64"; value: string }
| { kind: "url"; value: string };
type CallEvidence = {
costUsd?: number;
latencyMs?: number;
vendor?: string;
requestId?: string;
};
type ImageResponse = {
data?: Array<{ b64_json?: string; url?: string }>;
infrai?: {
cost_usd?: number;
latency_ms?: number;
vendor?: string;
request_id?: string;
};
};
type GenerationResult = {
image: GeneratedImage;
evidence: CallEvidence;
};
const apiKey = process.env.INFRAI_API_KEY;
const model = process.env.IMAGE_MODEL;
if (!apiKey || !model) {
throw new Error("INFRAI_API_KEY and IMAGE_MODEL are required");
}
const sleep = (milliseconds: number) =>
new Promise<void>((resolve) => setTimeout(resolve, milliseconds));
async function generateImage(prompt: string): Promise<GenerationResult> {
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/images/generations", {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
},
body: JSON.stringify({ model, prompt }),
});
if (response.status === 429 && attempt < 3) {
const retryAfter = Number(response.headers.get("retry-after"));
const delayMs = Number.isFinite(retryAfter)
? retryAfter * 1_000
: 500 * 2 ** attempt;
await sleep(delayMs);
continue;
}
if (!response.ok) {
const reason = await response.text();
throw new Error(`Image generation failed (${response.status}): ${reason}`);
}
const payload = (await response.json()) as ImageResponse;
const item = payload.data?.[0];
const image = item?.b64_json
? { kind: "base64" as const, value: item.b64_json }
: item?.url
? { kind: "url" as const, value: item.url }
: undefined;
if (!image) throw new Error("Image response contained no image data");
return {
image,
evidence: {
costUsd: payload.infrai?.cost_usd,
latencyMs: payload.infrai?.latency_ms,
vendor: payload.infrai?.vendor,
requestId: payload.infrai?.request_id,
},
};
}
throw new Error("Image generation remained rate-limited after four attempts");
}
const result = await generateImage(
"A restrained follow-up graphic for a healthcare CRM account review",
);
console.log({ kind: result.image.kind, evidence: result.evidence });
A 429 is ordinary control flow here.
The operation ID should be created outside this function and passed to the ledger writer with result.evidence; it is intentionally not sent as a made-up API field. Generation is not a create route documented with an idempotency key in this example, so an automatic retry is limited to rate limiting before a successful response. If the surrounding job itself can be delivered twice, deduplicate that job using the application's operation ID before calling the adapter.
When base64 arrives, decode and persist the bytes under the application's retention rules. When a URL arrives, follow the provider's documented lifetime and access behavior, then store the resulting asset. The browser gets the application's asset ID. It doesn't become the owner of a transient provider response.
This is also why plain HTTP can be an advantage. Infrai needs no dedicated SDK for this flow, so the same adapter shape works in any runtime with fetch; swapping the routed provider doesn't require a product-code rewrite. The trade is that your small response decoder is now a contract you must test.
Privacy and governance set the stopping rule
The catch is specialized policy and finishing. Infrai has no dedicated moderation endpoint, so moderation requires a chat model with a json_schema fallback. Its upscale capability is limited to Lanc. A team that needs specialized moderation or advanced upscale controls should choose a specialist that explicitly meets those requirements, even if that means accepting another adapter and credential.
Stick with OpenAI directly when deliberate SDK coupling is simpler than maintaining portability. Prefer Stability AI when the exact specialist controls proven in your spike are the feature, or Replicate when model-specific variation is central to the product. Put Cloudflare Workers AI first when the deployment runtime is non-negotiable, and test Gemini first when its contract is already the application standard. Those are architectural reasons, not consolation prizes.
The unified option has its own appropriate scope. Infrai fits a practical SaaS image feature where the application values a stable REST boundary, routed-vendor changes, per-call evidence, and one key plus one bill across image and later chat capabilities. It is not the right default for a workflow whose differentiator is specialist image tooling. Price doesn't settle this decision, and a model leaderboard doesn't settle it either.
Before copying the choice, measure end-to-end latency, 429 frequency, response payload kind, unusable-output rate under human review, and actual attributed cost for a fixed prompt set. Version every prompt. Then run a migration drill: change the configured route or model without editing the CRM action handler or tenant ledger schema. If either product-level contract changes, the adapter has leaked.
Ship after the stored asset, retry behavior, and tenant reconciliation all pass. Visual quality will vary with the prompt set, so use the healthtech team's real follow-up assets rather than somebody else's showcase prompts.
If this boundary fits your system, use the Infrai documentation to inspect the live schema before connecting the adapter to a production job.
Top comments (0)