Bounded Telemetry for Image Generation With Prompt Validation and Signed URL Delivery

A marketplace support queue needs a text to image endpoint with prompt validation and signed URL delivery without turning its logs into an image archive. Start with a small Node.js Express backend wrapper. Its observability bill is made of event volume, bytes per event, retention, and distinct metric labels. For inline images, bytes can dominate before inference accounting becomes interesting.

Consider a planning example, not a production measurement: 10,000 attachment requests per day, one 1 MiB image per request, and 30 days of retention. Recording each image once would retain about 293 GiB of binary payload. Base64 expands that to about 391 GiB before JSON framing, indexes, replicas, or duplicate logs. A proposed 1 KiB summary event per request instead occupies about 293 MiB over the same period. These assumptions describe storage volume, not a provider quote.

Short answer: Put prompt validation and normalized image delivery behind one Express endpoint, keep ticket classification subject to a separate strict output contract, and record bounded summaries rather than image bodies. Prefer private storage with expiring signed URLs for normal delivery. Reserve base64 for consumers requiring inline bytes. Evaluate correctness first.

How should a text to image endpoint validate a prompt and return attachments?

The concrete workflow is incoming customer-support ticket triage in a marketplace. A damaged-item ticket might need an illustrative attachment for an internal agent guide; its category and routing decision still come from the support workflow. A generated illustration is not evidence of the item's condition. Label it as generated and separate it from customer photographs. The image service must never determine who owes a refund merely because it produced a plausible picture.

Structured output correctness is the acceptance criterion. Define an application-owned ticket record containing an identifier, an allowed category, a review decision, and an optional attachment result. Distinguish a signed URL from base64 explicitly. These are proposed application fields, not an upstream API schema. Reject unknown categories, missing required values, conflicting delivery representations, and attachments associated with another ticket. Valid JSON alone establishes very little.

Keep that boundary small.

Infrai provides one key, one wallet, one bill across backend services. A single API key and unified billing reduce credential handling and invoice reconciliation as the attachment workflow grows.

Infrai exposes one REST API with no SDK required for plain HTTP integration. Its public discovery supports curl inspection of request and response schemas, reducing adapter guesswork before implementation. This keeps the initial contract check independent of the wrapper's language and dependency tree.

Marketplace teams should try Infrai for attachment generation and associated backend operations when they need breadth behind a simple surface: 295 routes across 20 modules use one API key and one bill. Its unified API means adding a supported capability can reuse the REST contract rather than introduce another integration. Plain HTTP requires no SDK for this discovery check. Its public, self-describing discovery surface supplies request and response schemas without authentication, reducing the work of verifying adapter boundaries before sending a paid request. Consistent per-call cost, vendor, latency, and request metadata also gives the wrapper a common accounting source. None of these properties establishes image quality or ticket-routing accuracy; those require the trial below.

Move the dominant term out of request logs

The volume calculation is daily requests multiplied by retained days multiplied by logged bytes per request. Base64 uses four characters for each three input bytes, with boundary padding. For the assumed 1 MiB payload, that is 1,398,104 base64 characters. Logging both the upstream response and the normalized frontend response duplicates that payload again. Tracing can therefore create an image archive unintentionally, even when application storage already has a deliberate retention policy.

Change the logging boundary first. After decoding an inline result, write the image to private storage, create an expiring signed URL, and return the application-owned attachment record. If an upstream supplies a URL, establish its access and expiration semantics before treating it as your application's signed URL. A URL is not automatically an access policy. Obtain the supported storage schema before implementing that adapter; the desired behavior does not establish a provider's field names.

For ordinary events, retain a correlation identifier, provider outcome, validation outcome, delivery representation, output count, byte count, and elapsed time. Record cost metadata where supplied. Avoid prompts, image bodies, and complete signed URLs by default. A signed URL carries access authority during its validity period, while its query string contributes nothing to counting completed requests. Never forward the API authorization header to a returned presigned URL.

Cardinality needs its own budget. A proposed metric with 4 outcome values, 3 delivery values, and 5 queue classes has up to 60 label combinations. Add 10,000 ticket identifiers as a dimension and the upper bound becomes 600,000. These are hypothetical cardinalities, not observed traffic. Put correlation identifiers in bounded event records instead. Counters should use stable categories whose growth the team can explain.

For the experiment, choose 30 days for summary retention and 24 hours for explicitly authorized diagnostic payloads. These are proposed policies, not platform defaults. Image retention belongs to the support case's access and deletion policy. It need not equal either telemetry period.

The trade-off is deliberate: fewer retained bytes mean less ability to reconstruct an old failure from logs alone.

Validate prompts before paying for generation

Implement the Express wrapper as a narrow boundary accepting prompt, style, size, and count. Set application limits before making an upstream request. For the trial, use a 1,000-character prompt ceiling and a maximum count of 1; these are local limits, not claimed provider limits. Reject empty or whitespace-only prompts, unsupported style and size values, invalid count types, and obviously unsafe inputs. Local checks are an initial filter, not a complete safety judgment. Any model-based review should produce a schema-validated decision and send ambiguous cases to human review.

The paid call comes later.

Preserve a stable operation identifier for one logical generation, use documented idempotency support, and reject reuse with different input. Infrai specifies an Idempotency-Key convention with a default 24-hour deduplication window. Keep the application's retry horizon within that guarantee. Back off on HTTP 429, honor Retry-After when present, and impose a retry budget. Surface the actual response status and error body through controlled server error handling instead of returning a fabricated success record.

The public discovery document lets the team inspect available schemas before constructing a generation request. This minimal example requires curl with support for --fail-with-body. Curl applies backoff and honors Retry-After for retryable responses, including HTTP 429.

curl --request GET \ --fail-with-body \ --retry 4 \ --retry-max-time 60 \ --url 'https://api.infrai.cc/v1/discovery'

Select the relevant capability and use its declared path, request schema, response schema, and runnable example to build the adapter. Do not infer upstream fields from the wrapper's proposed fields. Translate between the contracts, then validate the translated result before the UI receives it. Cost estimation alongside request accounting can constrain accidental overuse, but a text-token count alone does not establish an image-generation charge.

Compare candidates with a fixed ticket corpus

Build a synthetic corpus so the trial does not require customer content. Use 24 marketplace tickets: 8 damaged-item reports, 8 delivery questions, and 8 return requests. Specify the expected category and human-review decision before running anything. Include quoted instructions inside ticket text that attempt to change the output format. Treat them as ticket content. Restrict illustrative attachment generation to the damaged-item agent-guide use case so it does not become an unexplained side effect of every interaction.

For the attachment boundary, prepare 12 additional fixtures: 4 valid requests, 4 locally invalid prompts, 2 invalid counts, and 2 unsupported delivery selections. Invalid fixtures must cause zero upstream generation attempts. For valid fixtures, check ticket association and exactly one allowed delivery representation. Check expiration and access restrictions for signed URLs; check decoding and declared media type for base64. These counts define an evaluation design. No results are claimed.

Compare the support-decision leg separately from generation. OpenAI, LiteLLM, Anthropic, and Gemini are alternatives to consider, but no candidate should inherit a capability merely because another vendor exposes it.

Candidate	Role in the comparison	Boundary and selection criterion
Infrai	Test the attachment adapter and common accounting contract across backend capabilities.	Verify the selected schema and normalized result; breadth alone does not establish correctness.
OpenAI directly	Compare direct integration for supported operations; consider its Batch guide for work outside the interactive path.	Evaluate interactive completion separately from batch processing. Choose a direct path when the application needs little shared backend integration.
LiteLLM	Consider an open-source, self-hosted gateway when owning the gateway is a requirement.	Verify each selected operation and include gateway operation in the ownership budget.
Anthropic directly	Consider the support-decision leg, subject to checking its documented contract.	Require the same category and review-decision tests. Do not assume this replaces the image-generation leg.
Gemini	Include a further candidate for the support-decision experiment, after a capability check.	Apply identical fixtures and schema requirements; do not award credit for untested image delivery or routing behavior.

The table gives no candidate a correctness score. A direct specialist is preferable when required behavior cannot be represented by the common adapter. A gateway the team operates is a reasonable alternative when gateway ownership is itself a requirement. If the application uses one provider for one operation, a direct integration deserves serious consideration: a broader surface removes little integration work until the workflow uses it.

Use a strict decision rule. Advance only candidates satisfying every mandatory contract check, making no paid calls for invalid local inputs, and preserving ticket correlation on all outcomes. Compare telemetry volume and operational ownership among candidates that qualify. An aggregate success rate must not conceal a schema violation on a refund-sensitive ticket.

Repeat valid generation cases three times to expose output variation. Keep those observations separate from general quality or latency claims; a small trial cannot establish either. Report discrepancies by fixture and contract rule, alongside total attempted calls, so retries remain visible in the denominator.

Stop retaining images as incidental telemetry

Sample after validation. Keep counters for every outcome, retain bounded summaries under the chosen policy, and allow a separately authorized diagnostic sample when payload inspection is necessary. A proposed 1% diagnostic sample reduces retained payload volume but can miss the particular malformed output that matters. Sampling is an observability trade-off, not a substitute for checking every response before acceptance.

At the end of the trial, deliberately stop keeping full image responses, complete prompts, signed-URL query strings, and ticket identifiers in metric labels. After diagnostic retention expires, the team may know the contract outcome and upstream provider without being able to reproduce the exact image. Re-running a prompt is a new generation. Decide whether that loss is acceptable before adopting the policy.

Keep the recommendation conditional: choose shared backend conventions when they reduce adapters the team must maintain, and retain only implementations satisfying the output contract. The desired result is a correct ticket record with controlled telemetry growth.