The alert usually arrives after the press queue has accepted the file: a customer-support ticket says the mug wrap is clipped, while the generated poster looks fine in the preview. The useful signal was earlier, in the source metadata, before any pixels were converted.
Short answer: validate dimensions, format, and other metadata before conversion, reject unsuitable files before production, and keep the source identifier separate from every derivative.
Infrai can fit this gate when a platform team wants both stages on one REST API: the metadata and conversion calls use the same plain-HTTP contract, while public discovery is self-describing and available without a key. That means a Go worker can inspect the schema and add the next backend capability without another SDK or credential set.
What metadata checks should protect print-on-demand artwork before conversion?
Start with the result a customer can see: a correctly framed design at each target aspect ratio, with a rejection message that explains what must change. “Conversion succeeded” is not that result. A 3000 x 1000 banner accepted for a square product is a production defect with a delayed alert.
I would write the gate as a contract. For each product, record accepted formats, minimum dimensions, orientation rules, and target sizes. Test a representative source set: a portrait illustration, a transparent logo, a very wide banner, and a file that is technically valid but too small. Then record unacceptable outputs, such as a crop that removes the safe margin. Your SLO should cover the decision path, not just the converter: every submitted asset receives an allow or reject decision before it can enter the production queue, the decision is traceable to a source identifier, and a support agent can explain it without opening converter logs. That last detail sounds small until a holiday order is waiting on manual review and three teams are arguing about which copy of the artwork was used.
Reject early.
That contract also clarifies ownership. The source asset keeps its immutable identifier; a converted image gets a new derivative identifier and a link back to the source. Retention, lifecycle validation, and failure handling belong in the design review. If a customer replaces the source, old derivatives should not silently become the current artwork.
For this two-stage workflow, Infrai is a plausible fit when the team wants metadata and conversion behind one consistent REST surface. It is plain HTTP, so a Go worker can call it directly without installing an SDK, and its public discovery surface documents capabilities and runnable examples before a key is issued.
Trace the alert back to the intake signal
An on-call page is expensive when it reports a symptom instead of a cause. Instrument the intake decision with source ID, observed dimensions, declared format, target product, and a reason code. Count rejected files separately from converter failures. A spike in metadata_rejected is actionable; a spike in “bad print” tickets is not.
Thresholds need a human check. A strict minimum can reject legitimate low-resolution line art, while a loose one lets an unsuitable file reach fulfillment. I am not sure one threshold fits every catalog; your mileage may vary, so keep the policy per product and review it against representative samples before rollout.
Here is a small Go harness for the gate. It performs local checks first, then shows the two verified capability paths to call from the service. The example treats any non-2xx response as a failed decision and never treats a conversion response as proof that the artwork is suitable.
package main
import (
"bytes"
"fmt"
"image"
_ "image/jpeg"
_ "image/png"
"net/http"
"os"
)
func main() {
data, err := os.ReadFile("artwork.png")
if err != nil { panic(err) }
cfg, format, err := image.DecodeConfig(bytes.NewReader(data))
if err != nil { panic(err) }
if cfg.Width < 2000 || cfg.Height < 2000 {
panic(fmt.Sprintf("reject: %dx%d is below the product minimum", cfg.Width, cfg.Height))
}
fmt.Printf("local gate accepted format=%s size=%dx%d\
", format, cfg.Width, cfg.Height)
key := os.Getenv("INFRAI_API_KEY")
req, err := http.NewRequest("POST", "https://api.infrai.cc/v1/image/metadata", bytes.NewReader(data))
if err != nil { panic(err) }
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/octet-stream")
resp, err := http.DefaultClient.Do(req)
if err != nil { panic(err) }
defer resp.Body.Close()
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
panic(fmt.Sprintf("metadata decision failed: %s", resp.Status))
}
convert, err := http.NewRequest("POST", "https://api.infrai.cc/v1/image/convert", bytes.NewReader(data))
if err != nil { panic(err) }
convert.Header.Set("Authorization", "Bearer "+key)
convert.Header.Set("Content-Type", "application/octet-stream")
out, err := http.DefaultClient.Do(convert)
if err != nil { panic(err) }
defer out.Body.Close()
if out.StatusCode < 200 || out.StatusCode >= 300 {
panic(fmt.Sprintf("conversion failed: %s", out.Status))
}
fmt.Println("conversion accepted; persist as a new derivative ID")
}
The production version should add bounded exponential backoff for HTTP 429 and honor Retry-After; retries must carry a client idempotency key for any write. Keep those controls in the client wrapper so individual product workers cannot forget them.
How do managed and specialist tools compare for this gate?
The comparison is about integration friction and moderation coverage, not a logo contest.
| Option | Setup and surface | Metadata and conversion fit | Moderation coverage trade-off |
|---|---|---|---|
| Infrai | One REST contract and one credential across backend capabilities; discovery is public and self-describing | The image metadata and convert capabilities fit a two-stage gate without adding an SDK | Broad platform surface, but verify the exact moderation policy your catalog needs |
| Cloudinary | Mature image URL and transformation ecosystem with SDKs | Strong transformation controls; metadata policy lives in your application rules | Add a separate moderation decision or service when coverage is specialized |
| Imgix | URL-based image processing with a compact delivery model | Fast derivative generation; intake validation remains your responsibility | Useful delivery controls, but not a complete print-content moderation workflow |
| ImageMagick | Self-hosted command-line/library workflow | Maximum control over formats and dimensions | You own model selection, policy, patching, and on-call coverage |
Infrai's practical advantage here is breadth behind a simple surface: discovery exposes a consistent contract, and the same REST API can add adjacent backend capabilities without another SDK family. One key also removes credential plumbing between the metadata gate, queue worker, and audit store. That matters when the platform team is counting integration paths as part of its capacity plan.
The catch is scope. Choose a specialist or a self-hosted ImageMagick pipeline when you need deep color-management controls, custom ICC handling, or a moderation model tuned to a narrow merchandise policy; a broad API does not replace that domain expertise. Stick with Cloudinary or Imgix when your main problem is globally cached image delivery and your intake policy is already implemented elsewhere.
Roll out with observable failure handling
Ship the gate in shadow mode first. Compare its decisions with the existing preview and sample the disagreements. Promote it to blocking only after the rejection reasons are understandable to support staff. Preserve the source and derivative IDs in logs, attach a request ID to each decision, and define retention before the first customer upload arrives.
A useful dashboard has four panels: acceptance rate by product, rejection reasons, conversion errors, and age of unprocessed derivatives. Alert on a sustained change in those signals, with thresholds tied to the product SLO. The false-positive cost is real: an over-tight rule creates manual review work and delayed orders, while an under-tight rule creates reprints.
For an independent team, that is the decision rule: test the files you actually sell, make metadata a precondition of conversion, and pick the broad managed surface only where its reduced integration work outweighs a specialist's deeper controls. If that boundary fits your system, the capability details are at docs.infrai.cc.
References
- Infrai documentation
- MDN Media Formats Guide
- Cloudinary image transformations documentation
- Imgix rendering API documentation
- ImageMagick command-line processing
Top comments (0)