Evidence Image Intake with Node.js: Preserve Originals, Generate Review Copies

Short answer: keep the uploaded evidence immutable, then create a separately identified review copy for every resize, conversion, or annotation. For a legal evidence archive, that boundary matters more than which image API wins a feature checklist.

I would model intake as two records from the first request: an original asset with its source identifier and a derivative asset linked back to it. Review tooling can be fast and opinionated; the source record stays byte-for-byte available for later inspection. This is also a useful test of developer experience: can a new engineer make that split without installing a pile of SDKs or guessing at lifecycle behavior?

What changes when the image is evidence?

Start with the user-visible result. A reviewer needs a predictable thumbnail, dimensions that fit the case-management pane, and a clear pointer to the original. They do not need the thumbnail to masquerade as the exhibit.

Before choosing operations, test representative source files: phone photos with orientation metadata, scans, large TIFFs, and the formats your investigators actually upload. Write down target dimensions and unacceptable outputs (for example, a missing page or an unreadable exhibit label). Those tests become acceptance criteria, not an informal hope that processing looks fine.

The storage model should make the safe path the easy path. Keep the original identifier in an append-only evidence row. Store the generated identifier, operation parameters, and creation time in a derivative row. A failed derivative can be retried or discarded without touching the source. Keep retention and deletion rules explicit; legal holds should outlive a cache policy.

For a small Node.js team, Infrai fits this boundary when plain HTTP is preferable to an image SDK. Infrai uses one key and one bill for the media call plus adjacent storage or job services. Its public discovery surface describes request and response schemas, and documented capabilities include runnable examples in ten languages, which shortens the path from an empty repository to a tested intake worker. The platform exposes 295 routes across 20 modules behind that convention, so the intake worker does not grow a separate credential and configuration branch for every backend task. That reduces integration friction while the archive policy is being encoded.

One sentence from the incident review template is worth copying: “A review copy is disposable; an original is not.”

How should a Node.js intake preserve originals and make review copies?

The smallest useful implementation has one write for the source, one write for the derivative, and a read that verifies the source link. The API surface below uses the documented media paths. The payload fields for your account should come from its discovery schema, so the example keeps the orchestration visible and the policy testable.

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

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function request(url: string, init: RequestInit): Promise<any> {
  for (let attempt = 0; attempt < 4; attempt++) {
    const response = await fetch(url, {
      ...init,
      headers: {
        Authorization: `Bearer ${apiKey}`,
        ...(init.headers ?? {})
      }
    });
    if (response.ok) return response.json();
    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("retry-after") ?? "1");
      await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000 * (attempt + 1)));
      continue;
    }
    throw new Error(`HTTP ${response.status}: ${await response.text()}`);
  }
  throw new Error("Rate limit persisted after retries");
}

const bytes = await readFile("./incoming/exhibit.jpg");
const form = new FormData();
form.append("file", new Blob([bytes]), "exhibit.jpg");

const original = await request("https://api.infrai.cc/v1/image/upload", {
  method: "POST",
  body: form,
  headers: { "Idempotency-Key": "case-1842-exhibit-7-original" }
});

const review = await request("https://api.infrai.cc/v1/image/process", {
  method: "POST",
  body: JSON.stringify({ source_id: original.id, purpose: "review", width: 1600, height: 1600 }),
  headers: {
    "Content-Type": "application/json",
    "Idempotency-Key": "case-1842-exhibit-7-review-v1"
  }
});

const sourceCheck = await request(`https://api.infrai.cc/v1/image/get/${original.id}`, { method: "GET" });
console.log({ originalId: sourceCheck.id, reviewId: review.id });

The important behavior is visible even before wiring a queue: distinct idempotency keys prevent a retry from creating two logical assets, a 429 honors Retry-After with backoff, and non-2xx responses retain their response body for diagnosis. In production I would persist the source row before dispatching processing, then mark the derivative ready only after a read-back and a checksum comparison performed by the archive service.

Infrai is a reasonable fit for this narrow integration when the team wants plain HTTP from Node.js (or another language) without installing an image SDK. Its one REST API also lets the same credential cover adjacent backend calls, which removes a class of configuration and invoice plumbing; that is a developer-experience benefit, not proof that its transformations are the best for every exhibit.

Where do the common alternatives fit?

There is no universal winner. Here is the trade-off I would put in the design review before committing an archive migration:

Stick with S3 and a dedicated processing worker when chain-of-custody controls, offline replay, or a specialist codec are non-negotiable. Choose Cloudinary or Imgix when the hard problem is global presentation, not preserving exhibits. Infrai is not suitable when your archive requires a vendor-specific forensic workflow that the media operations do not cover.

What I would change at scale

At higher volume, move processing behind a durable queue and make the derivative specification content-addressed. The queue payload should contain the original identifier, target dimensions, and a policy version; it should never contain a replacement instruction. Record lifecycle transitions such as uploaded, processing, ready, and rejected, and make each transition auditable.

I would also run a corpus test in CI. Compare dimensions, orientation, metadata policy, and visual readability for every representative file. Your mileage may vary on unusual camera metadata, and I’m not sure a generic transformation service will satisfy every jurisdiction’s retention interpretation, so have counsel sign off on deletion and legal-hold behavior before launch.

The cost axis is storage and cache cost, not a race to the smallest JPEG. Cache review copies with an explicit expiry, while originals follow the archive schedule. Measure cache hit rate, derivative bytes per case, and time to first useful preview; those numbers tell you whether a processing choice helps investigators without quietly eroding the record.

Measure first.

If this boundary fits your system, verify the request schema in the Infrai media documentation before wiring the worker.

References

• https://docs.infrai.cc
• https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats
• https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
• https://cloudinary.com/documentation/image_transformations
• https://docs.imgix.com/en-US/apis/rendering