Gallery delivery
Upload originals and resume source imports
Product documentation · Reviewed
Create a standalone gallery or connect it to a wedding. Add chapters before uploading when you want files grouped as ceremony, portraits and reception. New originals are private while the gallery is a draft.
Upload and resume
The uploader accepts JPEG, PNG, WebP, TIFF and HEIC photos up to 150 MB, plus MP4 and MOV video up to 2 GB. It transfers originals in verified parts. Keep the same file selected to resume an interrupted upload; a different file needs a new upload identity. Completed parts are checked before reuse, and the stored object must match the expected size and checksum before it enters processing.
For example, if a large reception video stops halfway through, reconnect and select that original again. The uploader checks which parts reached storage and continues. A completed original then waits for its proof and web-size versions. Processing failures appear beside the file and can be retried. Completion of an upload is not proof that the client-facing derivative is ready.
Photos receive bounded web and proof derivatives. Proofs can carry the gallery watermark; originals are preserved separately. Video processing produces web playback and a watermarked proof. Private storage, background processing and an enabled media spending limit must be configured before these provider-backed operations can run.
Bring files from an existing account
Choose Import from Drive or Dropbox, connect the intended account, browse folders, select up to one hundred originals and choose a gallery chapter. The import job keeps a fixed source revision and uses the same verified upload pipeline. Google documents and shortcuts are not original media uploads.
The progress panel shows bytes and parts, plus pending, importing, paused, complete, canceled or failed status. Use Pause to stop subsequent chunks, reconnect the same source account and use Resume original to continue from storage-verified parts. Reconnection checks that the selected source revision, size and media type still match. A completed revision is deduplicated; selecting a changed revision creates a separate import. Source-account setup and real account authorization are part of activation, not something a demo fixture verifies.
Cancel import records the stop before cleaning up storage. A worker that was downloading a chunk cannot publish an original after that stop. If only multipart data reached storage, cleanup releases its existing reservation. If storage accepted a complete original but confirmation was lost, the original remains private, the recorded ingest reservation is settled and the private object is queued for deletion. A cleanup or spending error remains recoverable. Start again becomes available after storage cancellation is reconciled and creates a fresh upload identity.
Curate a collection without opening every photograph
The gallery workspace separates Collection, Share & deliver, Client activity, and Shop & orders. Start in Collection to upload originals and arrange the photographs. Delivery holds presentation settings, staged releases, individual client or vendor deliveries, reminders, and retention. Named favorites and comments live in Client activity. Shop & orders keeps customer purchases, returns, gift allowances, and download bundles together.
Collection shows 48 photographs at a time. Search by filename, caption, or person; filter by chapter, visibility, or processing state. Show next photographs reveals another group without losing your selection. Select all matches selects up to 250 matching files, including matches further down the collection. The selection bar explicitly counts selected files outside your current filters. Clear the selection before choosing a different group when those earlier files should be left alone.
Select photographs and choose Move, Make private, Make visible, People & tags, or Retry previews. Review the selected filenames and destination before confirming. Adding tags preserves the existing people on each photograph and ignores differences in capitalization; removing tags removes only the names you enter. Each photograph can have up to 50 tags. If any selected photograph would exceed that limit, none of the batch is saved.
Click a photograph to edit its caption, chapter, display order, tags, or individual visibility. These changes use the same authorized collection service as the API. Only a full private workspace member or a credential with assets:write may curate a collection; wedding participation alone does not grant that access.
Making a file visible does not override a private chapter, gallery password, delivery restriction, or download policy. Moving files into a private chapter keeps them private. Making the current cover private clears that cover choice so the gallery can use an available visible photograph. In a published gallery, saved visibility changes affect the current viewer experience immediately. Original files, historical purchases, and frozen production records remain intact.
Changes save as one atomic batch against the current collection revision. If another person replaces a photograph, changes a chapter, or saves a competing edit, refresh and review the selection again. An unchanged retry after a connection interruption uses the same request identity and returns the original saved result. Membership and gallery availability are checked again even for retries.
Retry previews queues only failed files whose original remains available. It does not retry already-ready or processing files. New processing generations prevent an older worker from publishing a stale result. Private storage, media workers, and usage enrollment still need activation before real processing is available.
Integrations can call POST /api/v1/galleries/{id}/curation with expectedRevision set to the gallery's mediaRevision, a stable UUID requestId, selected mediaIds, and a MOVE, VISIBILITY, TAGS, DETAILS, or RETRY operation. Keep the same body and request identity when retrying an interrupted response; use a new request for a newly reviewed change. The shared OpenAPI document describes the individual payloads.
Capture order and original versions
The media panel reads a bounded set of camera, lens and exposure fields plus the photograph's capture date. It does not retain GPS, owner names, camera serial numbers or private comments. Delivered derivatives strip source EXIF metadata. A camera date without an offset remains unresolved until you supply an IANA timezone or explicit offset. Ambiguous daylight-saving times require an explicit offset; the server timezone is never guessed.
Sort the current gallery or one chapter by capture time, filename or manual earlier/later controls. Files without a resolved capture instant follow dated files. Concurrent changes require reloading before applying a stale order.
To replace an original, choose the current photograph, upload the reviewed replacement, wait for its private preview and compare the versions. Applying it records the source and target checksums, your reason and whether named favorite selections should move. The old media and asset IDs remain intact for existing album proofs, exports and purchases. You can restore a prior version through the same reviewed flow. Canceled candidates stay private and are retained until explicit gallery retention cleanup. Replacing a current image does not silently alter a previously approved album.
This is a gallery delivery library, not continuous desktop-folder synchronization. Keep your own originals and read gallery access and retention before delivering the collection.
Recover after interrupted confirmation
Upload intents live for seven days. The background worker checks expired uploads before removing partial storage. For local uploads, if storage already accepted the complete original, the worker verifies its size and checksum, reconciles its existing spending reservation and continues processing. A paused or failed source import stays private until you resume it or explicitly cancel it; expiry does not bypass that decision. If only partial data exists, it aborts that multipart upload and releases the existing reservation. It does not create a new charge to cancel an old upload.
A missing or released reservation remains visible as an error that needs reconciliation. If storage succeeded but usage settlement was interrupted, the original stays recorded and the worker retries settlement. Derivatives and ZIP files also have saved output intents before writing; a lost response can recover the same private object rather than create an untracked duplicate. Changing a watermark starts a new processing generation so an older worker cannot publish outdated proofs.
Review a local directory and existing originals
The upload area’s Import a local folder & review duplicates panel checks every selected original in bounded 8 MiB reads before uploading. Choose a folder or files, a destination and whether to preserve directory paths. Relative directory paths become gallery chapter labels; the exact original path remains in the private import record, even when a long chapter label is shortened. Chapters remain the gallery’s existing independent folders, rather than inheriting a live filesystem tree.
A review contains up to 500 files. For a larger collection, choose its smaller subfolders in successive reviews. Supported photographs may be up to 150 MB and videos up to 2 GB. Unsupported files are left out with a count. Absolute paths, traversal segments and control characters are rejected.
The review compares complete provider-verified multipart checksums, byte counts and media types with existing originals in this gallery. It also identifies matching files earlier in the same batch. Names and sampled resume fingerprints do not establish duplicates. Originals stored with another checksum representation may not be recognized as duplicates; a missing match is not proof that the photograph has never been uploaded.
For every file, choose Upload a separate original or Skip this file. Refresh the review after changing decisions, then approve the exact files, destinations and estimated ingest usage. Original uploads still require the configured media rate, enrollment and spending cap. Derivative processing and ongoing storage are separate usage. A skip creates no upload or spending request. This workflow never replaces an existing photograph automatically.
If the gallery is already published, newly processed visible originals can appear under its current access settings. Prepare an unpublished gallery when the collection should stay quiet until release. Imported chapters keep their own visibility; an existing imported chapter is not a child permission container of its original destination folder.
The original review is retained before any upload begins. Upload completion compares the storage-verified checksum to the exact checksum approved in that review. If they differ, the bytes cannot become a ready gallery original under that approval.
Pause and resume the approved batch in the same tab. After a restart, select the same originals, destination and path-preservation setting. The browser’s retained upload identity finds the existing approval and verified multipart parts; another review does not create a second original. Prepare a fresh separate copy deliberately creates a new upload identity when a second copy is wanted or an old multipart upload expired. Clearing browser storage loses this convenience, but does not erase the retained server record or automatically remove prior originals.
Named full workspace operators can inspect the last 20 retained import reviews through /api/v1/gallery-local-imports; the same interface supports preview and approval. Scoped integration keys and shared-wedding guest invitations do not expose these private studio records. No new provider configuration is required beyond the existing private gallery storage, allowed upload origins, media pricing/caps and media-processing workers.