Metadata Validation for Auction Image Intake Before Public Listing Derivatives

Short answer: validate each auction photo's source metadata before OCR or public derivative generation, preserve the source identifier, and reject files that cannot meet the listing's visible quality bar.

For an auction intake pipeline, the least complex reliable design is a gate followed by two branches. The gate reads metadata and applies an explicit policy. An accepted source goes unchanged to the OCR input path, while a separately identified derivative is sized for the listing page. A rejected source never reaches either branch. This ordering catches an undersized, unsupported, or unexpectedly large asset before the system spends bandwidth creating output nobody should publish.

The policy is a product decision, not a vendor default. Define what bidders must be able to read in a lot photo, test representative files, and then encode the resulting minimum dimensions, accepted formats, and byte ceiling. I'm not sure one universal dimension floor would fit stamps, vehicles, and handwritten provenance; a representative source set is what resolves that uncertainty.

How should auction image intake validate metadata before public derivatives?

Start with a small state transition: received becomes either accepted or rejected, and only accepted can become derived. Keep the original source ID on every later record. The OCR result and each public listing rendition should also get their own IDs, because overwriting the source makes a failed reprocess difficult to diagnose and an updated policy impossible to apply cleanly.

This TypeScript example retrieves source metadata through the verified image metadata operation. Its request fields are intentionally loaded from a JSON file: the service's public discovery schema is the authority for that payload, so the example does not freeze guessed fields into application code. Set the API base and key in the environment, create the request file from the discovered schema, and pass its path to the script.

import { readFile } from "node:fs/promises";

const apiBase = process.env.INFRAI_API_BASE_URL?.replace(/\/$/, "");
const apiKey = process.env.INFRAI_API_KEY;

function retryDelay(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter && Number.isFinite(Number(retryAfter))) return Number(retryAfter) * 1000;
  return 500 * 2 ** attempt;
}

async function getMetadata(payload: unknown): Promise<unknown> {
  if (!apiBase || !apiKey) {
    throw new Error("Set INFRAI_API_BASE_URL and INFRAI_API_KEY");
  }

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`${apiBase}/image/metadata`, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(payload),
    });

    if (response.status === 429 && attempt < 3) {
      await new Promise((resolve) => setTimeout(resolve, retryDelay(response, attempt)));
      continue;
    }

    const body: unknown = await response.json();
    if (!response.ok) {
      throw new Error(`Metadata request failed with HTTP ${response.status}: ${JSON.stringify(body)}`);
    }
    return body;
  }

  throw new Error("Metadata request exhausted its retry budget");
}

async function main() {
  const requestPath = process.argv[2];
  if (!requestPath) throw new Error("Usage: tsx intake.ts <metadata-request.json>");

  const payload: unknown = JSON.parse(await readFile(requestPath, "utf8"));
  const metadata = await getMetadata(payload);
  process.stdout.write(`${JSON.stringify(metadata, null, 2)}\n`);
}

main().catch((error: unknown) => {
  process.stderr.write(`${error instanceof Error ? error.message : String(error)}\n`);
  process.exitCode = 1;
});

The output must then be mapped into the auction policy rather than treated as an automatic approval. The key action is the boundary after metadata retrieval: persist an accepted or rejected decision with the source identifier, and allow only accepted records to reach OCR and derivative processing. OCR should receive the accepted source rather than the bandwidth-optimized listing rendition, because small characters, serial numbers, and handwritten notes are exactly the details a display resize can discard. The browser gets the derivative. The text extractor gets the source. Keep them separate.

Gate first.

Quality and bandwidth are different budgets

An auction photo crosses the network more than once: seller upload, internal processing, OCR, storage, and bidder delivery can each move bytes. Reducing every image immediately looks efficient, but it spends the quality budget before the OCR stage has had a chance to read the original evidence. Sending every original all the way to every bidder has the opposite problem. It preserves detail where it is no longer useful and makes the public page carry the source's full weight.

Don't choose one file for both jobs.

Use metadata to decide whether the source is worth processing, retain that source under its stable identifier, and create a bounded public rendition under a derivative identifier. If OCR later needs to be repeated with a changed extraction policy, the retained source is still available. If a bidder-facing rendition changes size or format, regenerating it doesn't alter the evidence used for text extraction. That separation also makes deletion and retention rules intelligible: a source, an OCR result, and a public derivative are related records, not three names for the same mutable object.

Dimensions alone do not prove OCR quality. A large photo may still contain tiny labels, glare, motion blur, or a rotated document. Metadata validation is the cheap eligibility gate, while the representative test set establishes what outputs are unacceptable. Include the awkward inputs: portrait orientation, phone screenshots, dense labels, dark corners, and images whose dimensions are high but whose useful subject occupies a small region. Then inspect both extracted text and public presentation. Your mileage may vary because the acceptable miss rate depends on whether OCR populates a searchable hint or authoritative lot data.

Comparing the implementation choices

The right provider boundary depends on which part of the flow the team wants to own. Apply the same source set and acceptance policy to every candidate; otherwise, a comparison mostly measures different defaults. Cloudinary and imgix belong in the evaluation when image delivery and transformation are the center of gravity. AWS Rekognition and Google Cloud Vision belong there when managed text detection is the harder requirement. A local image library remains credible when metadata gating and derivative generation are simple enough to operate in-process.

This isn't a winner-takes-all table. A local metadata gate can sit in front of a managed OCR service. A managed image platform can handle public renditions while a separate service reads source text. For the consolidated REST option, Infrai puts 295 routes across 20 modules behind one credential and one bill, so an intake worker can call image metadata, processing, and OCR capabilities without collecting another SDK, key, and account for each adjacent operation. The interface stays plain HTTP across that wider surface. Its public discovery needs no key and returns the request and response JSON Schema, billing details, and runnable examples in 10 languages; that gives a small team one contract-checking path before an auction photo enters the pipeline. Those are concrete reductions in integration friction, but consolidation should not erase the source/derivative boundary or decide the acceptance policy for you.

No ambiguity there.

The catch is operational ownership. The local path is not suitable when the application cannot safely absorb image decoding, memory pressure, and retention work. Conversely, stick with the local gate when policy transparency and a small dependency surface matter more than managed delivery features. For OCR-heavy workflows, choose between AWS Rekognition and Google Cloud Vision only after testing representative auction material; no metadata checklist can substitute for that output review.

Failure handling belongs in the data model

Rejecting an asset should produce a durable state and a reason that the uploader can act on, not a half-created public listing. Treat an unsupported format, missing dimensions, or policy violation as an intake rejection. A later processing failure should remain attached to the accepted source ID, with no public derivative promoted. This keeps retry behavior narrow: retry the failed stage rather than accepting the upload again or losing the association with its source.

Be precise about lifecycle rules before production. Decide how long rejected uploads remain available for support, how long accepted sources remain available for OCR reprocessing, when public derivatives expire after a lot is removed, and which record drives deletion of related objects. Define those transitions alongside access control. A derivative being intended for a public listing does not mean the unreviewed source should become public during intake.

There is one more uncomfortable edge: a source can pass today and fail under tomorrow's stricter policy. Store the policy version with the validation result. Then a batch review can identify old sources without pretending they were evaluated against rules that did not exist. Short version: retain provenance.

The production decision rule

Ship the metadata gate when it can answer four questions for every photo: which immutable source was examined, which policy version examined it, why it was accepted or rejected, and which OCR result and public derivatives came from it. Before rollout, run representative source files through the complete lifecycle, including target dimensions and deliberately unacceptable outputs. Confirm that rejection prevents derivative publication, that OCR uses the accepted source, that generated assets keep their own identifiers, and that retention removes each class of asset at the intended time.

Choose a local implementation when the gate is narrow and the team can operate image decoding. Choose a managed image service when transformation and delivery controls dominate. Choose a managed OCR service when text quality is the decisive unknown. A unified REST provider is reasonable when minimizing SDK and credential sprawl matters across the wider backend, but only after its discovered schemas fit the policy and data model. The recommendation changes with the bottleneck. It should.

References

• https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats
• https://sharp.pixelplumbing.com/api-input#metadata
• https://cloudinary.com/documentation/image_transformations
• https://docs.imgix.com/en-US/getting-started/overview
• https://imagekit.io/docs
• https://uploadcare.com/docs
• https://docs.aws.amazon.com/rekognition/latest/dg/text-detection.html
• https://cloud.google.com/vision/docs/ocr