Webhook recipe: a reading log from your browser
Most reading logs end up in their own silo. A list of titles in Goodreads. A pile of highlights in Readwise. A folder of bookmarks you never reopen. Each system is fine on its own, but none of them know what else happened the day you finished the book.
A reading log is more useful when it sits next to the rest of your day. The article you read on the train, the meeting that prompted the book, the highlight that changed how you replied to a Slack thread. Reading is part of the day, not a parallel record.
deariary does not (yet) have a native Readwise or Instapaper integration. But it does have a webhook. With a small amount of setup, anything you read can flow into the same diary as your commits, calendar, and conversations.
What a reading log is, and what most apps get wrong
A reading log answers two questions: what did you read, and what stood out. Title plus highlight. Goodreads is good at the first. Readwise is excellent at the second. Neither connects either to the rest of your life.
The result is that a reading log written this way ends up read by no one, including its author. It is a database, not a diary. You can query it. You cannot sit down with a coffee and re-read it.
The reframe: route the reading data into the diary you already re-read. The titles and highlights become sentences in a paragraph that also mentions the meeting that morning and the run that evening. That is when reading starts to feel like part of a life, not an item on a shelf.
Three webhook sources for a reading log
Every option below ends at the same endpoint: POST https://api.deariary.com/webhooks/ingest with a Bearer token. What differs is where the data comes from.
1. A browser extension for the things you actually finish
The simplest setup is a tiny browser extension or bookmarklet that fires when you finish reading an article. One click, and the page title, URL, and any text you have selected go to deariary as JSON.
A minimal payload looks like this:
{
"event": "article_read",
"title": "The Field Guide to Genuine Hyperbole",
"url": "https://example.com/hyperbole",
"highlight": "Most writing advice is permission, not technique.",
"finished_at": "2026-06-21T10:42:00Z"
}If you do not want to write an extension, a bookmarklet is enough. It takes the current tab title and URL, prompts for an optional highlight, and posts the result. Five lines of JavaScript and a token from your settings page.
2. Readwise as the highlight source
If you already use Readwise, you have probably noticed that highlights pile up faster than you re-read them. Readwise can fire an outbound webhook on its paid plan whenever a new highlight is saved. Point that at deariary, and every highlight you make in Kindle, Apple Books, or your favourite read-it-later app appears in the diary for that day.
The Readwise payload arrives with the book title, author, highlight text, and (when present) a personal note. No transformation is needed: the entry just shows up. Use a token labelled readwise-highlights so the LLM knows the source is highlights rather than articles or finished books.
This setup requires no code. A Readwise account, a token from deariary, and a URL filled into the Readwise webhook field. That is the whole pipeline.
3. A finished-book signal
For books, the natural granularity is the moment you finish, not every highlight along the way. A small script (cron job, Shortcut, whatever you prefer) can fire a single webhook when you mark a book as done in Goodreads, Hardcover, StoryGraph, or your reading app of choice.
curl -X POST https://api.deariary.com/webhooks/ingest \
-H "Authorization: Bearer whk_your_token_here" \
-H "Content-Type: application/json" \
-d '{
"event": "book_finished",
"title": "Bewilderment",
"author": "Richard Powers",
"rating": 4,
"thoughts": "Hit harder than I expected. The Theo passages will stick."
}'The thoughts field is optional, but it is the field that makes the entry worth re-reading. A title and a rating is data. A sentence about why it landed is a memory.
What the diary entry looks like
Without the webhook, a Tuesday entry from your existing integrations might read:
A morning standup, two hours of focus work on the onboarding fix, lunch, and a long thread in #design about the empty state copy. The afternoon ran on Todoist. A walk after dinner.
With the reading-log webhooks layered in, the same day reads:
A morning standup, two hours on the onboarding fix, and an article about empty states you saved on the train and finished at lunch (“Most writing advice is permission, not technique”). The #design thread quoted the same line back at you by mid-afternoon. The Todoist list cleared in pieces between meetings. A walk after dinner, and you finished Bewilderment that night (“Hit harder than I expected. The Theo passages will stick”).
The difference is not the work. It is the seam between the article and the Slack thread, and the line about Bewilderment sitting next to the walk. That is what a reading log was always supposed to be.
Wiring the recipe
Webhooks are an Advanced-plan feature. From the Integrations page, generate a token with a descriptive name (reading-extension, readwise-highlights, or books work well), then paste the whk_-prefixed value into your bookmarklet, Readwise webhook field, or finishing-a-book script. Data starts arriving on the next entry.
For the full reference (endpoint URL, payload limits, multiple-tokens-per-account, how token names shape the diary), see the webhook integration deep dive.
Honest limits
A reading-log recipe is not a Readwise replacement. The recipe assumes you already have an account somewhere (or that a bookmarklet covers what you need). Whatever text you do not include in the JSON does not reach your diary, so a title and URL is fine, but a 30-page chapter is not. The same article fired three times shows up three times, since the recipe does no deduplication. And the diary catches what arrives from the day you wire it up forward, with no automatic backfill of old highlights.
If a native Readwise integration would change those answers, it is worth waiting for. If not, this recipe is enough.
Why a recipe instead of an integration
Native integrations exist for the apps where most of our users already live: GitHub, Calendar, Slack, Todoist, Trakt, Steam, Last.fm, and a growing list. Reading is more fragmented. Some people are deep in Readwise. Some have moved to Hardcover. Some never left Goodreads. Some only read RSS through their browser.
A single native integration would pick one and ignore the rest. A webhook recipe lets every reader plug in the source they already use, in the shape they already use it. That is the trade-off the webhook integration was built for: less polish at the edges, total flexibility about what enters the diary.
A reading log is a good fit for that trade-off. The barrier to capturing it has never been technology. It has been getting the data out of the silo it lives in. Five lines of JavaScript or a single Readwise webhook setting is the bridge.
deariary turns the data your tools already collect into a daily entry worth re-reading. With a webhook, anything you read can join that entry, even before there is a native integration for it.
