Beyond the official reMarkable desktop and mobile apps, a small ecosystem of community connectors moves documents on and off the Paper Pro. They exist because the device stores nothing by filename: every notebook is a UUID with .metadata, .content, and .thumbnail sidecars under /home/root/.local/share/remarkable/xochitl/, so a plain file copy produces an invisible, unreadable blob. Each connector solves the same problem differently — one ships in firmware, one rides the official cloud, one replaces the cloud entirely. Understanding where each runs and what it trusts is the groundwork for building your own pipeline in the next section.
Figure 8.1: Where each connector runs relative to the tablet and the reMarkable cloud
USB Web Interface (Built-In)
The simplest connector ships in the firmware. Enable it under Settings > Storage > USB web interface while the device is plugged in over USB-C. The tablet then presents itself to the host as a USB-Ethernet (RNDIS/CDC) device, takes the static IP 10.11.99.1, and serves a page for browsing folders and transferring files:
# HTTP only — HTTPS will not connect
xdg-open http://10.11.99.1/Uploads are drag-and-drop (PDF and EPUB only, ~100 MB cap); the file lands in the last folder opened in the browser. Downloads export a PDF with all annotations burned in. The page is backed by a small REST API served by xochitl, so transfers can be scripted:
# Script an upload instead of drag-and-drop
curl -F "[email protected]" http://10.11.99.1/upload
# List root-folder contents as JSON
curl http://10.11.99.1/documents/Other endpoints include GET /download/{guid}/pdf, GET /download/{guid}/rmdoc (firmware v3.9+), and GET /thumbnail/{guid}. There is no authentication: the security model is purely physical — anyone with a cable and the device can pull every document. The 10.11.99.1 endpoint also disappears when the cable is unplugged, though community tools (rM-self-serve/webinterface-persist-ip and webinterface-onboot) keep it reachable over Wi-Fi.
rmapi (Official Cloud CLI)
rmapi is a Go command-line client that talks to reMarkable's official cloud API — the same servers the tablet syncs to — entirely off-device. Use the maintained ddvk/rmapi fork; the original juruen/rmapi is archived and speaks only the old sync protocol. The ddvk fork implements sync protocol 1.5 (sync15), which modern accounts and the Paper Pro require.
Authentication is a one-time device registration: generate a code at my.remarkable.com/device/desktop/connect, paste it in, and rmapi stores the resulting tokens in ~/.rmapi (override with RMAPI_CONFIG).
# Interactive shell: browse the cloud like a filesystem
rmapi
# Non-interactive, scriptable — ideal for cron backups
rmapi put ~/reading/paper.pdf /Inbox
rmapi geta /Notebooks/Journal # download with annotations as PDF
rmapi mget /Notebooks ./backup # recursive directory downloadBecause it rides an unpublished API, firmware or cloud changes can break it; RMAPI_FORCE_SCHEMA_VERSION overrides protocol detection when needed. rmapi needs no Developer Mode or SSH, but it is an access tool, not a privacy tool — documents still transit and rest on reMarkable's servers, and the stored token is a long-lived bearer credential to guard like an SSH key. It can also be pointed at a self-hosted rmfakecloud instance.
rmfakecloud (Self-Hosted Cloud)
rmfakecloud, also by ddvk, is a self-hosted drop-in clone of reMarkable's cloud service. The tablet syncs natively — background, over Wi-Fi, through the normal UI — to your own server, with zero data on reMarkable's infrastructure. Redirection works by editing the tablet's hosts file so my.remarkable.com and local.remarkable.com resolve to your server, then installing a custom TLS certificate the tablet will trust. Both steps require SSH / Developer Mode access, and each official firmware update wipes them, reverting the device to the real cloud until you re-apply.
It implements sync protocol versions 1.0 through 4, is tested up to reMarkable software 3.27.1, and explicitly lists the Paper Pro, Paper Pro Move, and Paper Pure as supported. Deployment is primarily via Docker (Helm charts exist for Kubernetes); devices pair through a one-time code generated in its own web admin UI. Beyond sync it bridges documents outward: WebDAV (Nextcloud/Owncloud compatible, configured per user in a .userprofile), FTP, ICS calendar, email delivery, handwriting recognition, and a messaging webhook for automation platforms. Handwriting search and OneDrive are not supported.
Footgun: older versions delete all files on first connect unless you mark them as not-synced beforehand. Back up before pairing.
Trade-Offs and Security
The three connectors trust three different things: a physical cable, an official cloud token, or a TLS anchor you own. That choice drives every other trade-off.
| Approach | Needs dev mode / SSH? | Runs off-device? | Paper Pro support | Auth / trust model |
|---|---|---|---|---|
| USB web interface | No | No (on-device firmware) | Yes | None — physical cable access only |
| rmapi (ddvk fork) | No | Yes (CLI on your host) | Yes (use sync15 fork) | Official cloud device token in ~/.rmapi |
| rmfakecloud | Yes | Yes (self-hosted server) | Yes (explicitly listed) | Your own users + TLS cert |
The USB interface leaks everything to anyone holding the device but nothing to the network. rmapi keeps your data on reMarkable's servers and concentrates risk in one bearer token. rmfakecloud removes reMarkable from the trust path entirely, at the cost of owning uptime, backups, correct TLS handling, and re-applying the redirection after every update. For files over 100 MB or notebook-native pushes, none of these suffice — SSH into xochitl and generate the metadata scaffolding directly.
Figure 8.2: Choosing a connector by dev-mode need, location, and where data should live