Upgrade StorageGroup library collection created by API is not syncing to my local library
I'm editing a group library, and one specific collection that was created using the API will show up in the web version of Zotero but not in my local library. Their collections in the same group library are still working exactly as expected. I did update to the newest version and then discovered that some files were syncing that I didn't actually want in cloud storage. I deleted them, so I am not at storage capacity. I checked all my sync settings, and the collection that I'm working with is in a group library that should be syncing. Thanks!
Debug ID: D628411616
Debug ID: D628411616
(Note that you disabled syncing for My Library. If this is about a group, that's not relevant, but be aware that your personal library is not syncing.)
https://s3.amazonaws.com/zotero.org/images/forums/u1546794/smv34s3tdf5xgs0hvbkd.png
https://s3.amazonaws.com/zotero.org/images/forums/u1546794/n0f6brn1fthos1lmhje3.png
Debug ID: D628411616
To clarify — the collection I'm asking about was created via the API and has never synced to my local library since its creation, despite repeated syncs. Manually created items in this collection sync immediately (the first manually created item triggered the collection to show up locally), and I've also confirmed that editing an item that was created by the API does not cause it to sync either — so this isn't a matter of a change failing to come down, it's that the original API-created object never downloads, and edits to it don't trigger a fix. Here's a Debug ID from a sync attempt where it's still absent: D1815380389. The item I tried editing manually in the collection in question: https://www.zotero.org/groups/2187538/liturgy/collections/AB95AP6X/items/ZKAVVIX7/collection. Let me know if there's something else you'd like me to try.
The item that you say you edited manually hasn't changed online in two days. How exactly are you editing it manually?
That is helpful. You are right that my previous edit did not save at all, even online. I added a note and that saved and synced to the same item locally, but that item still does not appear in the collection. So the specific thing that isn't syncing locally is the data that these items (there are 39 now in the online collection, 37 were created by the API) are in the new collection.
I can't capture a URL for a unique item, nor do I see that there's any manual way of editing what collections an item belongs to besides clicking and dragging.
Thanks for looking at this.
If you can reproduce the original problem, starting with item creation, we'd want to see a Debug ID that covers the entire process.
I can now reproduce this, and the collection that started this thread is fixed. Reporting what I found in case you want to change how the call behaves.
What I was doing
The items were added to the collection by a script using the Web API, with this call (group library 2187538, Zotero-API-Version: 3):
POST /groups/2187538/collections/<collectionKey>/items
Content-Type: text/plain
Body: space-separated item keys
It returns 204 and the items do appear in the collection on the server (web library and API both show them).
What goes wrong
The call does not increment the library version. The affected items are stamped with the current library version instead of a new one.
Reproduced today, 5 October 2026:
1. Library at version 14720. Desktop client (Zotero 10.0.2, macOS) fully synced at 14720.
2. Sent the call above for one existing item, TBHHP53Y, into existing collection 9LTEBZUN.
3. Response: 204, Last-Modified-Version: 14720.
4. GET /items/TBHHP53Y now shows the collection in "collections" and "version": 14720 (it was 14696 before).
5. GET /items?since=14720&format=versions returns nothing.
6. Desktop client syncs, stays at 14720, and never shows the item in the collection. Its local copy of the item is still at version 14696.
So a client that is already at the current version has no way to learn about the change. This matches my original report: collection AB95AP6X had 39 top-level items on the server and 4 in the desktop client, three weeks and many syncs later.
It is easy to miss, because if the client happens to sync after the call for some other reason while still behind that version, the items do arrive. A second collection I filled today looked fine for exactly that reason.
For completeness: an item key that does not exist in the library returns 400 "Item 'XXXXXXXX' not found in library" and nothing is added, so that part behaves sensibly.
What fixed it
Writing the same membership through the items endpoint instead:
POST /groups/2187538/items
[{"key": "...", "version": N, "collections": ["<collectionKey>"]}, ...]
That increments the library version as expected (14720 to 14722 for one item removed and re-added; then to 14800 for the 39 items of the original collection), and the desktop client picked everything up within a minute.
Suggestion
I could not find the collections/<key>/items POST in the current v3 write documentation, so it may be a holdover from an earlier API version. Either of these would have saved me the confusion:
- have the call increment the library version like other writes, or
- have it return an error under API version 3 if it is not meant to be supported.
Happy to provide a fresh Debug ID or run anything else that would help.