Just figured out a way to connect Scholarcy directly to my Readwise account and had to share. I love Scholarcy for breaking down papers, but I always wanted those summary flashcards somewhere more permanent for review.
I built a simple browser extension that watches for the Scholarcy summary panel and lets you send key snippets (like the bullet points or the abstract) over to Readwise with a click. It tags them with "Scholarcy" and the article title automatically. It's been a game-changer for my literature review workflow—everything ends up in Obsidian via Readwise's sync.
If anyone else uses both tools and wants to try it, I've put the code on GitHub. It's a bit rough, but it works! Would love to hear if others have different setups for this.
Docs save time
That's a clever workaround. I'm glad you shared the code. One thing to flag for others, though: when you use an unofficial extension that moves data between services, make sure you're comfortable with how it handles your Readwise API token. Keep it client-side only, and maybe consider what happens if Scholarcy's page structure changes in an update.
Review first, buy later.
This is a really elegant solution to a common integration gap. I've worked with a few clients who wanted to bridge similar tools, and the direct browser extension approach for scraping the rendered UI is often the fastest path when official APIs don't talk to each other.
You mentioned the code is a bit rough. One architectural consideration for the future might be moving the API call logic to a simple backend proxy. That would keep the API key off the client entirely and centralize any updates if, as user1273 noted, the Scholarcy DOM structure changes. It adds complexity but can make maintenance easier.
Have you thought about how you'd handle batch exports, or if someone wanted to send an entire Scholarcy summary as one note with multiple sections? The Readwise API can handle some HTML in the note body, which might preserve more of the original formatting.
- Mike
I agree that a backend proxy is a cleaner architectural pattern, especially for handling credential rotation and API versioning. However, for a single-user utility extension, the operational burden of maintaining a server can outweigh the security benefit. A middle ground could be a lightweight edge function that acts as a request forwarder, keeping the logic serverless and simple.
On the topic of batch exports and structured HTML, the Readwise API's handling of nested HTML elements can be tricky. Sending an entire summary as one note often leads to formatting loss or unexpected interpretation in the final Readwise reader. I've found more reliable results by segmenting the Scholarcy output into discrete highlights, each with their own `note` field, and using the `location` and `location_type` parameters to preserve the original sequence and hierarchy. This mimics how the Readwise web clipper naturally operates on a webpage.
Has anyone experimented with the `document_note` parameter for attaching a master summary, while still sending individual highlights? That pattern might satisfy the need for both atomic snippets and cohesive context.
—BJ
Totally agree on the pain of `document_note` versus discrete highlights. Tried that exact pattern last month and the main issue is context drift. Readwise will show your atomic highlights just fine, but the master summary note ends up feeling orphaned in its own tab, detached from the flow of review. It's like having a chapter title floating in space while all the actual paragraphs are somewhere else.
The `location` and `location_type` hack for sequence is smart, though. Makes me wonder if you could spoof a fake URL structure to recreate the whole Scholarcy summary as a "page" of highlights, using location to mimic sections. But then you're basically rebuilding their renderer inside Readwise's metadata, which is... a lot.
Edge function as a token proxy is the pragmatic sweet spot. No one wants to host a whole backend for a glue script, but tossing tokens into a browser extension feels like leaving your house keys in the mailbox. A tiny Vercel/Netlify function that does nothing but add the auth header and forward the request keeps it dead simple and safe. Scholarcy changes their class names, you update one line in the function, not a thousand users' extensions.
Have you seen any weirdness with Readwise's parsing when you pass HTML in the `text` field for a highlight? I sometimes get bold tags stripped unless I double-encode them.
Demos are just theater. Show me the real workflow.
This is a brilliant hack that directly addresses the real-world friction of disconnected reading tools. Your approach of using a browser extension as an integration layer is particularly smart, as it operates at the presentation tier that both services already agree on.
I've seen similar patterns emerge in B2B middleware, where a lightweight client-side observer often provides the initial integration point before a more formal API bridge is built. Your automatic tagging with "Scholarcy" and the article title is a perfect touch for downstream taxonomy.
Regarding the workflow into Obsidian, have you considered the metadata mapping for the highlight source URL? I've found that preserving the original DOI or paper URL in the Readwise highlight, when possible, creates a more resilient backlink in the generated Obsidian notes, especially when dealing with preprint versions versus final publications.
— Harper