completely delete the cache
If the cache is causing memory issues, you can clear it, but this will hurt performance.
get the current cache value as a string
You can use this to warm start a new instance of
remarkable with any previously cached results.
get a document's entire contents as a zip archive
This gets every file associated with a document and puts them into a zip archive.
a reference to the document (e.g. from listItems)
This is an experimental feature. The resulting archive round-trips back
through putDocumentArchive.
get the epub associated with a document
This returns the raw input epub if a document was created from an epub.
a reference to the document (e.g. from listItems)
the epub bytes
get the pdf associated with a document
This returns the raw input pdf, not the rendered pdf with any markup.
a reference to the document (e.g. from listItems)
the pdf bytes
get a single page's parsed reMarkable lines (.rm) drawing
a reference to the document (e.g. from listItems)
the id of the page, from the document's .content page
list (see getRmPages for every page)
the parsed page, or undefined if the page exists but has no
.rm drawing (a page you haven't drawn on has no .rm file)
get every drawn page of a document, parsed, keyed by page id
Returns a map from page id to its parsed RmPage,
iterating in the page order given by the document's .content. Pages with
no drawing (and soft-deleted pages) are omitted. Version 3, 5, and 6 pages
are all supported.
a reference to the document (e.g. from listItems)
the drawn pages, keyed by page id, in document order
list all items
Items include both collections and documents. Documents that are in folders will have their parent set to something other than "" or "trash", but everything will be returned by this function.
if true, refresh the root hash before listing
a list of all items with some metadata
prune the cache so that it contains only reachable hashes
The cache is append only, so it can grow without bound, even as hashes become unreachable. In the future, this may have better cache management to track this in real time, but for now, you can call this method, to keep it from growing continuously.
Optionalrefresh: booleanwhether to refresh the root hash before pruning
upload a document archive produced by getDocumentArchive
This explodes the zip archive back into its constituent files, uploads each as a blob, and commits a new document into the root.
the archive bytes, as returned by getDocumentArchive
overrides for parent, visible name, and id
This is an experimental feature. By default a fresh document id is generated
so re-uploading to the same account doesn't collide with the original; pass
id to keep the original id. Like the other
low-level puts, this may throw a GenerationError
if the generation is stale, requiring a retry.
use the low-level api to add an epub document
Since this uses the low-level api, it provides more options than
uploadEpub, but is a little more finicky. Notably, it
may throw a GenerationError if the generation
doesn't match the current server generation, requiring you to retry until
it works.
the name to display on the reMarkable
the raw epub
put options
the entry for the newly inserted document
create a folder
use the low-level api to add a pdf document
Since this uses the low-level api, it provides more options than
uploadPdf, but is a little more finicky. Notably, it
may throw a GenerationError if the generation
doesn't match the current server generation, requiring you to retry until
it works.
the name to display on the reMarkable
the raw pdf
put options
the entry for the newly inserted document
When zoomMode is "customFit" the customZoom* fields describe the view,
all in the source page's device pixels: customZoomPageWidth and
customZoomPageHeight are the page dimensions scaled by the device dpi
(pagePt * dpi / 72, see deviceScreens), and the
centers are in those pixels.
The view always has the device's aspect ratio — you control its height and
position, not its shape. customZoomScale = screenHeight / viewHeight in
device pixels (screenHeight fixed per model, see deviceScreens), normalized to 1:1 native pixels: at 1 the view is
screen-tall, showing screenHeight / customZoomPageHeight of the page.
customZoomCenterX offsets the center of the view horizontally from the
page center, and customZoomCenterY is the absolute distance of the center
down from the top of the page; the view's width follows from its height and
the device aspect ratio.
The fields are a single document-wide setting, but customZoomCenterY is
applied against each page's own rendered height. On a page rendered taller
than customZoomPageHeight that distance is a smaller fraction of the page,
so the view sits higher and cuts off the bottom; on a shorter page it sits
lower and cuts off the top. customZoomScale (a ratio) and
customZoomCenterX (an offset from center) do not shift with page size.
update content metadata for a collection
a reference to the collection to update
the fields of content to update
a reference to the updated entry, with its new hash
update content metadata for a document
a reference to the file to update
the fields of content to update
a reference to the updated entry, with its new hash
update content metadata for a template
a reference to the template to update
the fields of content to update
a reference to the updated entry, with its new hash
upload an epub
the name to show for the uploaded epub
the epub contents
upload a pdf
the name to show for the uploaded epub
the epub contents
the api for accessing remarkable functions
There are roughly two types of functions.
Most of these functions validate the return values so that typescript is accurate. However, sometimes those return values are more strict than the "true" underlying types. If this happens, please submit a an issue. In the mean time, you should be able to use the low level api to work around any restrictive validation.