the id this api is registered under
This is the uuid passed to register, which reMarkable
stamps on everything this client does. Tablets use their serial instead.
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 a single page's text highlights
These are separate from the highlighter strokes drawn in a .rm scene.
a reference to the document
the id of the page, from the document's .content page list
the page's highlights, or undefined if the page has none
get a document's per-page template names
The .pagedata file lists one template name per page, in page order (an
empty string for a page with no template).
a reference to the document
the per-page template names, or undefined if the document has
no .pagedata
get a single page's layer metadata
a reference to the document
the id of the page, from the document's .content page list
the page's layer metadata, or undefined if the page has none
get every page's layer metadata, keyed by page id
a reference to the document
the layer metadata in page order, omitting pages with none
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
get a template attached to an item as a .template sidecar
This is distinct from a TemplateEntry (whose
template is its .content); collections and documents can carry a template
this way.
a reference to the item
the template content, or undefined if the item has no .template
listen for sync notifications
reMarkable sends one every time a device finishes syncing. It names the device, not what changed, so use it as a cue to re-read.
The socket is reopened when the server drops it, which happens every few minutes. Leaving the loop closes it. Session tokens expire after a few hours, and this throws once reconnecting with an expired one fails.
reMarkable authorizes the handshake with a header, which node and bun can
attach but a browser's WebSocket can't, so this is server side only.
the notifications, in the order they arrive
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: boolean
whether to refresh the root hash before pruning
permanently delete an entry
Unlike delete, which moves an entry to the trash where
the device can still restore it, this drops the entry from the account
outright. Its files stay in the cloud, but nothing points at them anymore
and nothing brings the entry back.
Only the entry named goes: purging a folder leaves everything inside it
pointing at a parent that's no longer there. Those entries stay in the
account and listItems still returns them, but no
folder holds them, so nothing browsing the tree will find them. Purge the
contents first, or use purgeTrash, which takes the
whole tree.
a reference to the entry to purge
permanently delete everything in the trash
Trashing a folder doesn't touch what's inside it — those entries keep naming the folder as their parent, which is what lets the device restore them together — so the trash holds the whole tree hanging off it, not just the entries whose parent is "trash". This purges all of it in one root write.
if true, refresh the root hash before purging
references to the entries that were purged
Finding that tree means reading every item's metadata, so this costs about
as much as listItems.
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 and visible name
This is an experimental feature. A fresh document id is generated, so
re-uploading to the same account doesn't collide with the original. 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
set a document's per-page template names
a reference to the document
one template name per page, in page order, an empty string for a page with no template
a reference to the updated document, with its new hash
write a single page's layer metadata, replacing any already there
a reference to the document
the id of the page, from the document's .content page list
the layer metadata to write
a reference to the updated document, with its new hash
write several pages' layer metadata in one commit
a reference to the document
the layer metadata to write, keyed by page id, replacing any already on those pages and leaving every other page alone
a reference to the updated document, with its new hash
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.
write a single page's reMarkable lines (.rm) drawing
a reference to the updated document, with its new hash
write several pages' reMarkable lines (.rm) drawings in one commit
a reference to the updated document, with its new hash
attach a template to an item as a .template sidecar
a reference to the item
the template to attach, replacing any already there
a reference to the updated item, with its new hash
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.