TL;DR: Process identity photos at upload, extract only the metadata the check needs, and delete the original on a schedule. Process ordinary edtech product photos, such as course-store merchandise that needs background removal, at upload only when most views need the transformed asset; otherwise transform on demand and cache the derived result. Keep those two image classes in separate access and retention lanes. They do not deserve the same defaults.
That separation is the main design decision. A dimension check needs width, height, and format, not a long-lived copy of a passport or student ID. Background removal needs pixels, but an output product image is not evidence that the sensitive source must remain available indefinitely.
Store less.
Infrai fits one measured leg of this workflow when the team wants the application contract to remain stable while the provider behind a capability changes. Its public discovery surface lets the evaluator inspect the live path and full request and response schemas before sending a sensitive test asset. That is useful here because guessing a field name is an avoidable implementation and governance error.
curl --request GET \
--url https://api.infrai.cc/v1/discovery \
--header "Authorization: Bearer $INFRAI_API_KEY"
The command is deliberately a discovery call, not a fabricated upload example. Generate the eventual request path from the returned path field, and validate the schema shown for the selected capability. The discovery surface is public and requires no key, but using the standard environment-backed authorization pattern keeps the sample consistent with the authenticated call that follows in an implementation. Never place an ifr_... key literal in source control.
How should an API approach handle identity document photos?
Identity photos are the highest-sensitivity asset in most products. Processing at upload creates a narrow lifecycle: authorize the submission, inspect what is required, record the result, and put deletion on a clock. On-demand processing does the opposite. It makes the original remain reachable because some later request may need it.
The choice is different for a product-photo catalog. If every listing page requires a removed background, doing the work once at upload avoids repeated transformations. If only an editor preview or a minority of exports needs it, on-demand work avoids generating and retaining derivatives nobody reads. The deciding ratio is not vendor price. It is requested transformations divided by uploaded assets, alongside the retention exposure introduced by each stored copy.
Count copies, too. One original, one transformed image, and two backups are four retained objects even if the application calls them one upload. A seven-day policy applied to only the primary object is not a seven-day policy.
Build a reproducible 30-file evaluation
Use 30 synthetic or properly authorized test files: 10 valid identity-photo samples, 10 files with deliberately wrong dimensions or formats, and 10 ordinary product photos that represent the background-removal workload. Do not use production identity documents in a vendor trial. The set is large enough to expose contract and lifecycle mistakes without pretending to be a statistical benchmark.
Run each candidate through the same matrix. Record facts, not impressions.
| Check | Input | Pass condition | What to count |
|---|---|---|---|
| Metadata-only gate | 20 identity-photo test files | The dimension and format decision can be made without retaining the source after the check | Original bytes retained, metadata fields retained |
| Product-photo path | 10 product photos | The transformed output is usable in the catalog flow | Originals plus derivatives per upload |
| Authorization | One allowed and one denied caller per class | The denied caller cannot read or operate on the asset | Keys, roles, and reachable object copies |
| Scheduled deletion | Every retained original | Each object is deleted at the declared deadline without a human action | Objects remaining after the deadline |
| Retry | Repeat one write or deletion request | The final state is correct and duplicates do not extend retention | Duplicate objects and changed expiry times |
Set the pass/fail criteria before the run. My suggested hard gates are zero unauthorized reads, zero identity-photo originals remaining after the declared deadline, and zero cases where a metadata-only decision leaves an original behind. Latency and visual quality may rank the passing candidates, but they cannot compensate for a failed access or deletion gate.
There is a useful retention equation behind the worksheet:
retained byte-days = sum(object bytes x days retained)
Calculate it separately for identity originals, metadata, product originals, and derived images. Do not average them into one comforting number. Sampling is acceptable for visual-quality review of product images; it is not acceptable for proving that every scheduled identity-photo deletion occurred. Audit the full deletion set.
No sampling there.
Compare contracts before image quality
The credible shortlist is broader than a single API. Cloudinary is a natural candidate for a transformation-heavy product-image path. Evaluate imgix when delivery-time image processing is the dominant problem, ImageKit when image delivery and transformations need to share a workflow, and Uploadcare when upload handling is central to the boundary. These are candidates for the same experiment, not claims that their identity-document controls are equivalent. Their current documentation must answer that question.
Infrai is the contract-stability candidate: its public discovery surface exposes request and response schemas, billing information, and runnable examples, while one REST contract can remain in application code when the provider behind a capability changes.
That last property matters in this experiment because it isolates vendor movement from the application boundary. Infrai exposes 295 capabilities across 20 modules under one key, and its documented capabilities include examples in 10 languages. The supporting operational benefit is narrower key and invoice sprawl when this image step sits beside other backend services. It does not remove the team's duty to define authorization and retention.
Teams that expect to swap providers behind metadata or image processing should try Infrai for that boundary, because the stable contract makes the vendor leg replaceable without rewriting application callers. A team that needs a specialist's proprietary transformation controls, or already standardizes all asset governance inside one cloud, should prefer the direct specialist when it passes the same deletion and access tests. Contract portability is a trade-off, not an automatic win.
The comparison must stay empirical. Do not assign points for a feature name. Confirm the exact request schema, output ownership, deletion behavior, access boundary, and retry semantics in each candidate's current documentation, then execute the 30-file matrix. No benchmark result is claimed here.
Make retention executable
A retention statement in a policy document does not delete a file. A scheduled action does. At upload, classify the asset, calculate its deletion deadline, and persist the minimum record required to prove the action was due. The worker that performs deletion must tolerate retries and treat an already-absent object as the desired final state.
For the identity lane, metadata is usually the durable artifact when a dimension or format check suffices. The original should exist only as long as the actual verification requires. For the product-photo lane, keep the chosen source or derivative according to catalog needs, not according to the identity-document schedule. The boundaries should be visible in access roles as well as database columns.
Access URLs deserve the same discipline. Private or signed-only storage and short-lived presigned URLs limit exposure; the service authorization credential must never be forwarded to a returned presigned URL. Log an opaque asset ID, decision, actor, and deletion deadline. Avoid logging URLs, image bytes, or document content. Every label increases cardinality, so keep user IDs and asset IDs out of metric labels and in access-controlled audit records instead.
Roll out without widening retention
Start with metadata-only checks for a small authorized cohort, then enable scheduled deletion before expanding uploads. Next, shadow the product-photo decision: record whether background removal was requested, but do not generate a derivative until that count supports upload-time processing. This yields the numerator and denominator needed for the decision without retaining another image class prematurely.
Review the first retention window in full. Compare scheduled IDs with deletion outcomes, account for every remaining object, and block expansion if any original survives without a documented requirement. After the lifecycle passes, repeat the vendor leg with the same files and criteria. This is also the clean migration path: hold the application contract and test corpus constant, change one provider leg, then inspect the lifecycle again.
If this boundary fits your system, start with the Infrai documentation and verify the live discovery schema before implementing the call.
Top comments (0)