Collection history
See what changed in your collection and safely undo a change.
Activity in the app
Open Activity from the collection's manage menu. Entries are grouped by day and say what happened, with the card, person and local time.
Simple additions and removals are compact receipts. Choose View changes for meaningful before/after values such as a printing swap; bulk changes expand a few at a time. A previous member is labelled Previous member; an unattributed entry stays Unknown. These labels do not invent historical profile names.
Filters searches the complete recorded history, including deleted cards. Choose a collection, person, action or inclusive UTC date range. Older page and Newer page follow server cursors, so long histories stay reachable. Displayed times use your device's timezone.
Undo a change
Undo works for recorded copy, slot and collection changes, such as adding, moving, assigning, removing or regrading a copy, slot edits, bulk changes and creating a collection. Choose See what undoing does to get a preview from the server, then Undo this change to apply it. If the change can no longer be undone, the preview says so and offers nothing to apply.
When a change removed cards, tick the ones to bring back. They return to your collection as Unassigned copies, not to a pocket. Undoing the creation of your default binder asks which binder should open first instead.
The server checks current access and later changes before applying. A newer edit to the same data is a conflict, and there is no force overwrite. Undo adds a new history entry linked to the original, and the original shows Undone once its linked undo is on the loaded page.
Settings, sharing and appearance changes cannot be undone from Activity.
Offline and connection failures
Previously opened activity pages remain available on this device with their last-update time. They are saved pages, not a complete offline history. Reconnect to load another page or start an undo. Pending local edits must sync first.
A confirmed undo is saved on the device before it is sent, so a lost connection or reload does not lose it. The app shows Undo saved on this device until the server confirms it, then checks your collection again before showing Undone. Use Try again or Check my collection to continue; a retry sends the same request and cannot apply it twice. If the server rejects the undo because your collection changed, nothing was applied. You can then Discard this undo and Start a new undo from a fresh preview.
REST and MCP
Developer access requires current entitlement, credential grants and owner/linked-partner access. The app uses its signed-in session. Responses are private and use no-store. Public share links have no private Activity.
list_collection_audit (GET /collection/audit) and get_collection_audit (GET /collection/audit/{id}) require collection:read. Event IDs are strings. Lists return data and nextCursor, with up to 100 entries. Keep the same filters when following a cursor. Filters include collectionId, pokemonId and cardId (matched against slot targets, owned copies and wanted cards), inventoryItemId, slotId, actorId, action, since, until and recoveryOfEventId. The last filter finds undo events linked to an original. An undo entry also includes recovery_of_event_id.
Undo through REST and MCP uses the native storage recovery operations (preview_storage_recovery, apply_storage_recovery and their v2 forms), described below. Each entry's changes lists the rows it changed, reduced to the fields Activity shows. Private certificates, label assets, uploaded artwork references and share tokens are never returned in history or recovery responses.
Every write records one entry as part of the same transaction, so history and the collection never disagree. Binder renames, reordering, layout, sharing, appearance and settings saves are recorded too.
Native storage recovery
The app and the registered REST/MCP operations use the same recovery executor. A preview lists public-safe changes and explicit conflict reasons; applying it needs the exact reviewed plan, explicit confirmation and a retry-stable operation ID. There is no offline optimistic restoration and no automatic replacement request.
Recovery rejection
The v1/v2 apply contract declares REST 409 storage_recovery_rejected, or MCP isError:true, only for a committed strict error.rejection containing outcome:"rejected", the original operationId, known code and inventoryRevision. Codes are recovery_plan_conflict and recovery_dependency_conflict. Arbitrary 409/SQL errors, missing receipts, cancellation and billing/access errors are not noncommit proof. Exact accepted/rejected replay requires current authority and precedes mutable plan reconstruction.
After a committed rejection, the app reads your current collection again before offering Discard this undo. A discarded undo is kept as discarded, never as applied. A new undo needs a new preview, explicit confirmation and a new operation ID. Unknown and accepted requests can only be retried or checked, never discarded. No private inverse, evidence, certificates or assets are exposed.
Find an exact operation
REST GET /app/api/v1/collection/audit?operationId=synthetic-original-operation and MCP list_collection_audit with {"operationId":"synthetic-original-operation"} find the exact original operation within your currently authorized history. The example ID is synthetic. Keep the same filters when following nextCursor, then use get_collection_audit with the selected event ID to inspect it. An empty result does not prove that a command failed. Multiple events require choosing an exact event; never use the newest event as a guessed inverse. Operation IDs are bounded opaque strings, up to 200 characters without surrounding whitespace or line breaks. Private recovery evidence remains server-only.