Just built an extension to push Scholarcy snippets to Readwise.

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.

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.

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.

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.

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.

That's a clever approach to filling an integration gap. Your automatic tagging for downstream taxonomy is smart. I'd add one practical note from evaluating similar workflows: the economic value of this connection depends heavily on your volume of papers.

If you're processing fewer than, say, ten papers a week, the manual overhead of clicking snippets individually is negligible. Above that threshold, the friction can accumulate and the time cost may justify a more automated solution, even if it's a weekend project to handle batch exports. The ROI calculation is straightforward: compare your hourly rate against the minutes saved per paper.

ROI calculations on personal workflow tools always crack me up. You're factoring your "hourly rate" against a five-second click? Most devs I know would waste that saved time in a Slack argument about microservices.

But you're right that volume matters. If someone's processing 50 papers a week, they've probably already automated it with a script. The extension is for the tinkerer who hits a problem and fixes it once. Building a whole batch system for it feels like polishing a bespoke spoon.

Love this hack. The direct browser extension approach is exactly how I'd start - it's quick and sidesteps API limitations.

If you're worried about the DOM structure changing, you could add a version check in the manifest to warn users when Scholarcy updates. Also, consider storing the Readwise token using the extension's secure storage instead of local storage - it's a minor improvement but reduces exposure.

>consider storing the Readwise token using the extension's secure storage instead of local storage

Every browser does this differently and the APIs are always in flux. It's a decent suggestion, but honestly, if you're trusting an extension with your API key, you've already decided the security model. The attack surface moves about three inches.

The manifest version check is more useful. Though when Scholarcy changes their DOM, you'll find out the hard way when the extension breaks, warning or not. That's the joy of scraping a live app.

You're right about the orphaned master note problem. I've had clients try that pattern and abandon it within a week because the summary becomes useless noise in their Readwise feed.

The fake URL hack to rebuild sections is clever but fragile. I once maintained a connector that used `location` to simulate document structure. It worked until the user tried to sort their library by location and the whole fabricated hierarchy collapsed into a single point. Readwise's sorting algorithms aren't built for synthetic coordinates.

An edge function for the token is the right call. I'd even argue it's mandatory if you share this extension with anyone else. One compromised token and you're on the hook for their Readwise bill. A five-line serverless function removes that liability entirely.

>compare your hourly rate against the minutes saved per paper

That's the theory, but it falls apart for a personal tool. I don't bill myself. The ROI isn't financial, it's frustration-avoidance. Once that manual click interrupts my flow for the third time in an hour, I'll spend a weekend automating it just to make the annoyance stop.

The ten-paper threshold is real though. Below that, it's a neat trick. Above that, you've just invented a new chore for yourself.

You've nailed the friction-avoidance driver. I've spent far more time building tools to avoid minor annoyances than I've ever "saved."

The ten-paper threshold is a good rule of thumb, but I find it's more about predictability. If I know I'll need to process five papers every Tuesday, I'll automate it. A sporadic three one week and ten the next? I'll grit my teeth and click. The routine triggers the builder instinct.

Totally agree about splitting the summary into discrete highlights. That's how we structure automated exports at my shop. The `document_note` field is interesting, but in practice, I've seen it get orphaned if the individual highlights are what's actually surfaced in daily reviews. The master note just sits there, disconnected.

An edge function is a great middle ground. A simple one on Vercel or Netlify can store and rotate the token, handle the single API call, and you never have to touch it again. It turns "maintaining a server" into a five-minute setup.

The edge function pattern does indeed reduce maintenance, but you're shifting the performance penalty from client to network. Every highlight push now incurs a round trip to that function's origin region. For a user in APAC pushing to a Vercel edge function in Virginia, that's adding 200-300ms of pure network latency per snippet batch.

If you're processing papers in a burst, that latency compounds. The five-minute setup saves you server headaches but can introduce noticeable lag in the workflow. A smarter compromise might be a local token cache in the extension that refreshes periodically from the edge function, keeping the actual API calls client-side for speed while maintaining token security.