Upgrade StorageSupport for local API write access?
Is there any timeline for R/W local API access? Currently, only read access is supported.
The website says "Write requests are currently unsupported. Only GET is accepted. (An upcoming version of Zotero will support write requests.)", see https://www.zotero.org/support/dev/web_api/v3/local_api
(I would like to transfer items from a group library to the main library while preserving the identifier and the date added, without web synchronization. Is there any way to accomplish this today?)
The website says "Write requests are currently unsupported. Only GET is accepted. (An upcoming version of Zotero will support write requests.)", see https://www.zotero.org/support/dev/web_api/v3/local_api
(I would like to transfer items from a group library to the main library while preserving the identifier and the date added, without web synchronization. Is there any way to accomplish this today?)
My plan for synchronization (one-way, from several systems to one catch-all library):
- Incoming items end up in Group Libraries via Zotero's synchronization
- Run external script to copy the items and children from "Group Libraries" to "My Library". Most importantly, preserve "Date Added", because that's how I sort items. Otherwise I would just drag and drop between libraries.
- For convenience, use same item key (the 8 character alphanumeric string, not the integer itemID)
- Separately sync the attachments by copying the folders
- Eventually delete original items in Group Libraries
I thought that using the same item keys makes it easier to keep track of items and attachments, and as items are scoped to the library, there shouldn't be a conflict.
If key collisions are an issue, I could keep track of the renames in an external database and rename the attachment folders correspondingly. It would be just an inconvenience.
DELETE now work against the local API for items, collections and saved searches,
along with file uploads.
Writes need a local API key, which is not something you create in advance. A
client asks for one at runtime by posting its name to /api/local/authorize, and
Zotero shows a dialog with Allow, Always Allow and Deny. Every write also has to
carry a Zotero-Server-ID header identifying the instance, so a stale client
cannot write into the wrong library after a data directory change.
Documented at https://www.zotero.org/support/dev/web_api/v3/local_api
I built an MCP server on it, in case a working example is useful:
https://github.com/dvdsosa/zotero-native-mcp
No plugin, no zotero.org API key, and nothing leaves the machine.