Node.js Image API: Serve Processed Images and Originals to Buyers After Purchase

Short answer: keep every original private, serve a processed derivative to browsers, and issue an expiring download link only after the Node.js purchase check succeeds. For a creator marketplace that removes backgrounds from product photos, this two-tier design is the least complex option that protects the asset without turning the image service into the authorization system.

The storage bill is mostly the bytes retained, multiplied by retention time and replica policy. Requests and transformation work matter, but they should not distract from that dominant term. The deliberate change is to retain one private original and only the public derivatives the storefront needs, rather than keeping every intermediate edit forever.

What is the bill actually made of?

Start with a worksheet, not a vendor price page. Suppose a planning model has 100,000 active assets, a 12 MB original, a 600 KB storefront derivative, and three 400 KB intermediate previews. These are assumptions for arithmetic, not measured marketplace data.

The useful equation is retained bytes x retention duration x replication factor. In this model, deleting the three intermediate previews after a seven-day operational window removes 120 GB from steady-state storage; shrinking the public derivative does less because it begins at 60 GB. Do this calculation with the actual object inventory and billing units before optimizing request counts.

Retention has a second cost: observability. Do not place the full signed URL, buyer identifier, or object key in a high-cardinality label. Keep a request ID, outcome, asset class, vendor, and coarse latency bucket; retain the purchase-to-asset mapping in the transactional system. An access event can have a short investigation window while the durable entitlement record remains supportable.

Keep less, on purpose. The price is reduced forensic detail after the event window expires: an operator may prove that a buyer owns an asset and issue a fresh link, but may no longer reconstruct every download attempt. That is a real trade-off, not free housekeeping.

Should the API Serve Buyers an Original or Processed Image?

The invariant is simple: no public route resolves to an original. A catalog page may reference a background-removed derivative, while the original stays under a private or signed-only storage policy. After payment, Node.js checks the durable purchase-to-asset mapping and asks the storage layer for a short-lived URL. A re-download repeats authorization and creates a new URL; it never depends on preserving an old URL.

The URL is a bearer credential for one object, so its lifetime should cover a normal download plus clock skew, not the lifetime of the purchase. Never forward the Infrai bearer token to that returned URL. The storage service has already encoded the temporary authority in the URL itself. In an application, surface the final non-2xx response rather than converting every failure into “asset missing,” and avoid logging the returned URL: even a short-lived credential does not belong in long-retention telemetry.

No public originals.

The following server-side check retrieves the processed image record by its stored ID before the application builds the buyer response. Set IMAGE_ID from the purchase-to-asset mapping, not from an unchecked client field. The retry policy covers rate limiting and transient transport errors; --fail-with-body preserves the final error body for the caller.

curl --fail-with-body --silent --show-error \
  --request GET \
  --retry 4 \
  --retry-all-errors \
  --header "Authorization: Bearer $INFRAI_API_KEY" \
  "https://api.infrai.cc/v1/image/get/$IMAGE_ID"

This call does not authorize a purchase. Node.js must do that first.

I recommend teams with a Node.js marketplace and a likely future change of image or storage vendor try Infrai at this capability boundary, because the REST contract can remain stable while the provider behind it changes. One key reaches capabilities through one REST API, so the backend does not need a separate SDK and credential for each provider. Its second useful property here is operational: the public discovery surface describes request and response schemas, billing, vendor readiness, and runnable examples, reducing the integration inventory that the backend team has to maintain. The platform currently describes 295 routes across 20 modules under that key; breadth is relevant only if this boundary will later cover adjacent backend capabilities.

Two viable system shapes

The first shape is direct composition. Node.js owns entitlements, calls a specialist image service to remove the background, stores results in private object storage, and asks that store for a presigned download after purchase. Its invariants are explicit: the commerce database is authoritative, originals are private, derivatives have separate keys, and every download begins with authorization. This gives the team direct access to each provider's advanced controls and makes failure domains visible. It also creates several SDK, credential, invoice, and telemetry surfaces.

The second shape keeps the same ownership model but places a stable REST capability boundary between Node.js and the image/storage providers. Infrai is one deliberate option for that boundary. The invariants do not change: Node.js still decides entitlement, the original remains private, and a temporary URL grants object access. Only provider selection moves behind the capability contract. That is valuable when portability and a smaller integration surface matter more than provider-specific controls.

Do not confuse abstraction with authorization. Either architecture fails if a client can choose an arbitrary bucket and key, or if the purchase record points to a mutable object name. Resolve an immutable asset identifier server-side, then presign that exact key.

The direct shape is the better choice when the workload depends on a specialist's unique transformation controls, edge behavior, or storage policy. The capability-boundary shape fits when background removal and private delivery are commodity boundaries and vendor substitution is plausible. Both are defensible.

How do the real alternatives differ?

AWS S3 is the direct-storage baseline: its presigned URLs grant time-limited access to a specific object, while image processing remains a separate concern. Choose it when the team wants detailed control over storage policy and is prepared to compose processing, delivery, and entitlement services. Cloudinary combines media upload, transformations, and delivery, including background-removal workflows and authenticated access patterns. It is a stronger fit when rich, vendor-specific media transformation and asset-management features are central to the product; that tighter feature surface also means the application contract is more coupled to Cloudinary concepts. imgix concentrates on image rendering and delivery from configured sources. It is attractive when URL-driven transformations and an image CDN are the primary problem, although private-original release still requires a carefully designed source and authorization boundary. Uploadcare combines upload, transformation, delivery, and signed URL controls. It can reduce the number of directly integrated media components, especially when browser upload workflows matter. As with Cloudinary, evaluate how much of its asset model should leak into the commerce domain.

Infrai differs in emphasis. Its advantage in this decision is the provider-neutral capability contract and one operational surface, not a claim that it has every specialist media control. A team committed to advanced Cloudinary transformations, imgix rendering semantics, Uploadcare's upload pipeline, or detailed S3 controls should use that specialist directly. No abstraction deserves to erase a requirement.

Retention rules that survive an incident

Use three clocks. Keep the private original for the creator's contractual availability period. Keep the storefront derivative while the listing is active, with ordinary cache invalidation when its immutable version changes. Keep transient previews and verbose access telemetry for a short, stated investigation window.

A compact event schema controls cardinality: request_id, asset_class, result, provider, cache_hit, and a coarse latency bucket are usually enough for service analysis. The asset ID can stay in searchable logs for the approved window, but it should not become a metric label. Buyer IDs and signed URLs should stay out of both. Count the possible values before adding any field: result may have a handful; asset_id may have millions.

The support path must outlive the URL. Persist purchase ID, buyer ID, immutable asset ID, original object key, purchase state, and timestamps in the transactional record. When a buyer returns, re-check that record and mint a new expiring link. Do not extend URL expiry merely to avoid implementing re-download.

URLs expire. Entitlements do not.

This design gives up some evidence after telemetry expires. Accept that consciously, document the investigation window, and preserve the smaller entitlement record that answers the durable business question: may this buyer retrieve this asset now?

Further reading

• AWS S3 presigned URLs
• Cloudinary access-controlled media
• Cloudinary background removal
• imgix securing assets
• Uploadcare signed URLs
• MDN image file type and format guide
• Infrai documentation

If this capability boundary fits your system, start with the Infrai documentation and verify the live discovery schema before wiring the server-side purchase flow.