Accessing/Editing Notes through API

[Tarunima]

Hello,

I am using Pyzotero to access and edit information of papers in a library. We're using notes extensively in this library but the notes are not in the dictionary returned by the zotero.items method. Notes are also not returned by zot.everything. Is it possible to retrieve and edit or add notes to items through the API? If yes, could someone please direct me to the documentation for this? Apologies I have missed this. I did my best to find this information.

Thank you!

Tarunima

[Tarunima Prabhakar]

Hello, 

I eventually found the answer in some of the previous emails in this group. 

Thanks and apologies for redundant first email. 

Best, 

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zotero-dev/4b8131b7-ac9a-40c5-b78e-86c840833a0cn%40googlegroups.com.

[ja...@trailimage.com]

I am going to resurrect an old topic since I’m not able to find the helpful “previous emails” it referred to.

I am using the API to fetch things. It all seems fine except for notes attached directly to references (not annotation type notes—I am seeing those). For example, I have this entry:

and when I GET /users/<user-id>/items/<item-id>/children I get back that snapshot item but not the “arbitrary note.” 

I have clicked the manual-sync button in the client and allowed some hours to elapse but I still can’t retrieve the note. Some pointers would be appreciated! 

Kind regards, Jason

[ja...@trailimage.com]

A tad more information: I looked in the local SQLite database and found the note in the itemNotes table, then looked in items to see synced = 1 and to grab its key to try

/users/<user-id>/items/<key>

which returned 404

[ja...@trailimage.com]

FWIW, I double-checked keys/current and confirmed

{

  …

  "access": {

    "user": {
      "library": true,
      "files": true,
      "notes": true
    },
    "groups": {
      "all": {
        "library": true,
        "write": false
      }
    }

[Dan Stillman]

We'd always want the exact URL you're requesting to say more, but if the item doesn't exist online (which you can see just by checking the web library — you don't need to inspect the database), this isn't an API question. See Changes Not Syncing and post to the forums with the requested info if you're still having trouble.

- Dan

On 1/2/25 9:25 PM, ja...@trailimage.com wrote:

FWIW, I double-checked keys/current and confirmed

{

  …

  "access": {

    "user": {
      "library": true,
      "files": true,
      "notes": true
    },
    "groups": {
      "all": {
        "library": true,
        "write": false
      }
    }

  }

}

On Thursday, January 2, 2025 at 5:09:55 PM UTC-7 ja...@trailimage.com wrote:

A tad more information: I looked in the local SQLite database and found the note in the itemNotes table, then looked in items to see synced = 1 and to grab its key to try

/users/<user-id>/items/<key>

which returned 404

On Thursday, January 2, 2025 at 4:28:20 PM UTC-7 ja...@trailimage.com wrote:

I am going to resurrect an old topic since I’m not able to find the helpful “previous emails” it referred to.

I am using the API to fetch things. It all seems fine except for notes attached directly to references (not annotation type notes—I am seeing those). For example, I have this entry:

[ja...@trailimage.com]

Thank you, Dan. I checked and the note is synchronized to the web client and to my other devices so I don’t think it’s a synchronization or client issue. I assume I’m overlooking something with the API.

Given

• a base URL of https://api.zotero.org/users/8855486
• a note with the text “some abstract note”, key=63FJHN2N, parent key=EH9DZV7W
• local SQLite SELECT COUNT(*) FROM itemNotes = 66

these are the endpoints where I’ve been expecting to see the note:

/items/63FJHN2N → 404

/items/EH9DZV7W/children → web page snapshot item but not the note item

/items?itemType=note → empty JSON array

/items?since=7250 → Nine items, all older than the note

What does work

As far as I can tell, I’m getting expected results at all other endpoints. I can retrieve 1,545 items from my library, I can view group memberships and libraries, I can download files, etc.

I created a new API key but it didn’t change any of these results.

~ curl --header "zotero-api-version: 3" --header "authorization: <redacted>" -v https://api.zotero.org/users/8855486/items/63FJHN2N
* Host api.zotero.org:443 was resolved.
* IPv6: (none)
* IPv4: 54.163.69.245, 3.230.84.168, 52.54.139.76, 44.199.148.25, 54.158.84.138, 44.217.76.234
*   Trying 54.163.69.245:443...
* Connected to api.zotero.org (54.163.69.245) port 443
> GET /users/8855486/items/63FJHN2N HTTP/2
> Host: api.zotero.org
> User-Agent: curl/8.7.1
> Accept: */*
> zotero-api-version: 3
> authorization: <redacted>
>
* Request completely sent off
< HTTP/2 404
< date: Fri, 03 Jan 2025 17:05:08 GMT
< content-type: text/html; charset=UTF-8
< content-length: 9
< server: Apache/2.4.62 ()
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< zotero-api-version: 3
< zotero-schema-version: 28
<
* Connection #0 to host api.zotero.org left intact
Not found

[ja...@trailimage.com]

Solved it.

I am using a fancy API tool but wanted to offer a curl statement in the last message. In doing so, I noticed the key wasn’t prefixed with “Bearer” in the authorization header. The tool has a value selector it calls “Bearer Token” so I believed it was formatting it accordingly. And, indeed, pretty much all endpoints worked, so I didn’t think to question it.

Manually putting in the header as “Bearer <key>” fixes everything.

[Dan Stillman]

OK, in case it's not clear, that's because 1) you have your personal library set to be published publicly and 2) you have "Publish notes" disabled. So anonymous requests — which is effectively what you were making — wouldn't see notes.

(Bizarre that a tool with a "Bearer Token" option wouldn't add the "Bearer" prefix, though.)

On 1/3/25 12:29 PM, ja...@trailimage.com wrote:

Solved it.

I am using a fancy API tool but wanted to offer a curl statement in the last message. In doing so, I noticed the key wasn’t prefixed with “Bearer” in the authorization header. The tool has a value selector it calls “Bearer Token” so I believed it was formatting it accordingly. And, indeed, pretty much all endpoints worked, so I didn’t think to question it.

Manually putting in the header as “Bearer <key>” fixes everything.