Bulk Uploading Images & ZIP Files

Place the front and back image files for your cards in one folder. For best results, use the naming convention:

• cardname_F.jpg for front images
• cardname_B.jpg for back images

RocketVault automatically pairs fronts and backs based on matching names (before the _F or _B suffix). Every card needs both sides. Before processing begins, RocketVault checks the ZIP and reports any front-only or back-only filenames; it never creates an unprocessable card record for an unmatched image.

Scanner filenames may restart in a later image batch. RocketVault isolates each submitted batch, so reusing names such as card-001_F.jpg and card-001_B.jpg does not overwrite an older card or carry its identification into the new scan.

Scanning with running numbers instead? If your files are numbered 001.jpg, 002.jpg, 003.jpg… set the Pairing Mode to By number (even/odd). RocketVault sorts by number and pairs each two in a row into a card — you pick whether even or odd numbers are the fronts. Keep the sequence gap-free so pairs don't shift.

Your saved Pairing Mode applies to both image batches and ZIP contents. Choose By filename suffix for files such as card_F.jpg / card_B.jpg; choose By number (even/odd) only for consecutive numbered scans.

You can select image files directly in the upload picker or drag them into the drop zone. On a paid plan in the RocketVault web app, you can also compress those paired images into one .zip file and drop that ZIP into the same upload screen.

Open Vault → Upload in the RocketVault web app.

Drag front-and-back image files into the drop zone, or — on a paid plan — drag in a .zip file containing those images. RocketVault pairs matching images and starts background processing after the upload completes.

Before starting the upload, optionally enter a Storage location such as A1. RocketVault applies it to every card in that image batch or ZIP. You can search the code later, change it on an individual card, or replace it for a selection with Bulk Edit.

If a ZIP is marked Partial, its complete pairs were accepted but one or more filename groups were missing a front or back. Expand the batch to see the unmatched names, fix only those files, and upload the corrected pairs. If RocketVault says No complete front/back pairs found, rename every pair with a shared base name such as card-001_F.jpg and card-001_B.jpg before trying again.

The middle pane shows the per-batch metrics panel:

• Uploaded / Run / Queued / New / Merged / Failed tiles
• A progress bar split between done, errored, and currently running cards
• An expandable Pipeline section that breaks down stage-by-stage timing for the batch

The right pane streams a live event log as cards process. You can navigate away from the page after the upload completes — processing continues in the background.

Once complete, your recent batches stay in the left pane. Click any batch to expand its metrics and pipeline panel. Failed cards can be reprocessed individually via Failed Images, or use the bulk Reprocess Failed action on the batch.

Use Review on a completed history row to open the batch workspace. Every card has a reversible state: Approve, Resolve, Hold, Reject, or return it to Pending. RocketVault shows the current reason set and prevents an approval while any reason is unresolved. If new processing evidence changes the reasons on another device, RocketVault rejects the stale write and reloads the latest item before you decide again.

Only review-enabled uploads expose Review. Legacy uploads created before durable review remain available through Cards but do not open an empty workspace.

Cards from a review-required batch are staged inside that batch first. They do not appear in the main inventory, inventory filters, bulk selection, or publish flows until you complete the review. The workspace shows compact front/back image-quality findings and whether a quality override was recorded, so a warning can be handled as a retake or an intentional override before approval. Direct uploads larger than 20 files may be processed as multiple child jobs, but the history row and review workspace treat the shared upload session as one tenant-scoped batch. Cards in later child jobs remain visible and are finalized with the representative history row.

If RocketVault temporarily pauses the auditable review workflow during an operator rollback, the Review control is hidden before it can issue a disabled request. The same kill switch disables provisional staging and its visibility/publish guards together, restoring the legacy inventory path without changing or deleting card or upload data.

Run Check duplicates before finishing the batch. Possible matches require an explicit Keep both, Mark for merge, or Not a duplicate decision. RocketVault never auto-merges a preflight suggestion. Exact grader certification numbers strengthen a match, conflicting certification numbers are surfaced as evidence for possible OCR correction, and an active marketplace link is shown so a listed card is not silently replaced. The decision is shared with every later single-card, bulk, draft, imported-card, and lot publish. Keep both and Not a duplicate suppress the unchanged pair. Mark for merge records intent but keeps provider publishing blocked until you run the exact two-card Consolidate duplicates preview or change the decision. A marked pair means two scans of the same physical card, so the retained quantity does not increase. For another legitimate copy, choose Keep both and manage the separate record or quantity intentionally. This preflight uses stored identity and certification data; RocketVault does not currently store or compare perceptual image hashes.

Run Check front/back pairing when the capture came from a two-pass or numbered scan. RocketVault validates the complete session's side labels and identity stems, shows both images for any conflict, and requires an explicit confirmation before staging a changed mapping.

The review is not finished until every card is Approved, Resolved, or Rejected and you select Complete batch. Hold and Pending are deliberately unfinished states, so the completion control stays disabled while either remains.

The Recent completions strip keeps the last few approvals, resolutions, and rejections one tap away. You can undo any of them until batch completion; the reason fingerprint and decision versions prevent an already-resolved reason from reappearing unless its underlying evidence actually changes.

Completion is an atomic, auditable handoff. Approved and resolved staged cards become permanent inventory in the same transaction that writes the completion timestamp. Rejected cards remain batch-scoped and do not become publish candidates. After completion succeeds, every decision is immutable: item actions, duplicate preflight, and undo are disabled. If anything changed on another device before completion, RocketVault reloads the current decisions and asks you to review them before trying again.