Zotero Web API Documentation

The page documents read requests available in the Zotero Web API, providing read-only access to online Zotero libraries.

The base URL for all API requests is

https://api.zotero.org

All requests must use HTTPS.

Multiple versions of the API are available, and production code should always request a specific version. This page documents API version 3, which is currently the default and recommended version.

Clients can request a specific version in one of two ways:

1. Via the Zotero-API-Version HTTP header (Zotero-API-Version: 3)
2. Via the v query parameter (v=3)

Use of the Zotero-API-Version header is recommended for production code. The v parameter can be used for easier debugging and sharing of API requests or in clients that can't pass arbitrary HTTP headers.

The API version of a response will be returned in the Zotero-API-Version response header.

At most times, API changes are made in a backwards-compatible manner. Occasionally, however, backwards-incompatible changes may need to be made. When this occurs, a new API version will be made available without changing the default version for clients that don't request a specific version. After a transition period, the new API version will become the default. If an API version is discontinued, clients requesting the discontinued version will receive the oldest available version. Announcements regarding API version transitions will always be made ahead of time on zotero-dev.

Authentication is not required for read access to public libraries.

Accessing non-public libraries requires use of an API key. Third-party developers should use OAuth to establish credentials or instruct their users to create dedicated keys for use with their services. End users can create API keys via their Zotero account settings.

API keys can be included in requests in one of three ways:

1. As an HTTP header in the form Zotero-API-Key: P9NiFoyLeZu2bZNvvuQPDWsd
   
2. As an HTTP header in the form Authorization: Bearer P9NiFoyLeZu2bZNvvuQPDWsd
   
3. As a URL query parameter, in the form key=P9NiFoyLeZu2bZNvvuQPDWsd (not recommended)

Use of an HTTP header is recommended, as it allows use of URLs returned from the API (e.g., for pagination) without modification.

Authorization: Bearer is also the authentication mechanism for OAuth 2.0. While Zotero currently supports only OAuth 1.0a, when support for OAuth 2.0 is added, clients will no longer need to extract the API key from the OAuth response and pass it to the API separately.

Requests for data in a specific library begin with /users/<userID> or /groups/<groupID>, referred to below as <userOrGroupPrefix>. User IDs are different from usernames and can be found on the API Keys page and in OAuth responses. Group IDs are different from group names and can be retrieved from /users/<userID>/groups.

(Note: Only search metadata is currently available, not search results.)

The following parameters affect the format of data returned from read requests. All parameters are optional.

The following parameters are valid for all read requests:

Note the difference between format=bib and include=bib/content=bib. format=bib returns a formatted bibliography as XHTML, sorted according to the rules of the selected style. include=bib (valid only for format=json (the default format mode) and format=atom) returns an individual formatted reference within the JSON data block or Atom <content> block for each item, with the results or feed sorted according to the query parameters. format=bib processes the entire feed you are requesting without regard for any limit arguments, so it is generally a good idea to use it only with collections or tags.

The following bibliographic data formats can be used as format, include, and content parameters for items requests:

These parameters can be used to search against items when returning tags within items. In such cases, the main parameters (q, qmode, tag) apply to the tags themselves, as the primary objects of the request.

itemType and tag parameters support Boolean searches:

Examples:

• itemType=book
• itemType=book || journalArticle (OR)
• itemType=-attachment (NOT)

• tag=foo
• tag=foo bar (tag with space)
• tag=foo&tag=bar (AND)
• tag=foo bar || bar (OR)
• tag=-foo (NOT)
• tag=\-foo (literal first-character hyphen)

Be sure to URL-encode search strings if required by your client or library.

The following parameters are valid only for multi-object read requests such as <userOrGroupPrefix>/items, with the exception of format=bib requests, which do not support sorting or pagination.

Responses for multi-object read requests will include a custom HTTP header, Total-Results, that provides the total number of results matched by the request. The actual number of results provided in a given response will be no more than 100.

When the total number of results matched by a read request is greater than the current limit, the API will include pagination links in the HTTP Link header. Possible values are rel=first, rel=prev, rel=next, and rel=last. For some requests, the header may also include a rel=alternate link for the relevant page on the Zotero website.

GET https://api.zotero.org/users/12345/items?limit=30

Link: <https://api.zotero.org/users/12345/items?limit=30&start=30>; rel="next",
 <https://api.zotero.org/users/12345/items?limit=30&start=5040>; rel="last",
 <https://www.zotero.org/users/12345/items>; rel="alternate"

(Newlines are inserted here for clarity.)

For efficient usage of the API, clients should make conditional GET requests whenever possible. Multi-object requests (e.g., /users/1/items) return a Last-Modified-Version header with the current library version. If a If-Modified-Since-Version: <libraryVersion> header is passed with a subsequent multi-object read request and data has not changed in the library since the specified version, the API will return 304 Not Modified instead of 200. (Single-object conditional requests are not currently supported, but will be supported in the future.)

While a conditional GET request that returns a 304 should be fast, some clients may wish or need to perform additional caching on their own, using stored data for a period of time before making subsequent conditional requests to the Zotero API. This makes particular sense when the underlying Zotero data is known not to change frequently or when the data will be accessed frequently. For example, a website that displayed a bibliography from a Zotero collection might cache the returned bibliography for an hour, after which time it would make another conditional request to the Zotero API. If the API returned a 304, the website would continue to display the cached bibliography for another hour before retrying. This would prevent the website from making a request to the Zotero API every time a user loaded a page.

In addition to making conditional requests, clients downloading data for entire Zotero libraries should use ?since= to request only objects that have changed since the last time data was downloaded.

See Syncing for more information on library and object versioning.

[Not all rate limits are currently enforced, but clients should be prepared to handle them.]

Clients accessing the Zotero API should be prepared to handle two forms of rate limiting: backoff requests and hard limiting.

If the API servers are overloaded, the API may include a Backoff: <seconds> HTTP header in responses, indicating that the client should perform the minimum number of requests necessary to maintain data consistency and then refrain from making further requests for the number of seconds indicated. Backoff can be included in any response, including successful ones.

If a client has made too many requests within a given time period or is making too many concurrent requests, the API may return 429 Too Many Requests with a Retry-After: <seconds> header. Clients receiving a 429 should wait at least the number of seconds indicated in the header before making further requests. They should also reduce their overall request rate and/or concurrency to avoid repeatedly getting 429s, which may result in stricter throttling or temporary blocks.

Retry-After can also be included with 503 Service Unavailable responses when the server is undergoing maintenance.

Several examples of read request URLs and their responses:

Successful GET requests will return a 200 OK status code.

Conditional GET requests may return 304 Not Modified.

For any read or write request, the server may return a 400 Bad Request, 404 Not Found, or 405 Method Not Allowed for an invalid request and 500 Internal Server Error or 503 Service Unavailable for a server-related issue. Authentication errors (e.g., invalid API key or insufficient privileges) will return a 403 Forbidden.

Passing an Expect header, which is unsupported, will result in a 417 Expectation Failed response.

Library/object versioning or Zotero-Write-Token errors will result in 412 Precondition Failed or 428 Precondition Required.

429 Too Many Requests indicates that the client has been rate-limited.

• Write Requests
• File Uploads
• Syncing
• OAuth Authentication
• Changes from API Version 2