Obsidian daily notes into your diary, via webhook
There is no Obsidian integration. There is a webhook, and the files are markdown on local disk, which is enough to build the bridge yourself in an evening.
This is the shell-script version. Whether the two tools are even solving the same problem is argued elsewhere; assume here that you have decided they are complementary.
Two constraints up front. Webhook access sits on the Advanced plan. And traffic runs one direction only: markdown goes out, nothing comes back in.
The endpoint, briefly
The webhook guide covers token creation and payload rules in full. The short version for this job: one POST to https://api.deariary.com/webhooks/ingest, a whk_-prefixed bearer token, any valid JSON up to 100 KB, no schema. Name the token obsidian so the payload arrives labelled.
Everything below is about getting markdown out of a vault and into that request without mangling it.
The one-line version
If the files follow the default YYYY-MM-DD.md naming, the whole bridge is this:
#!/bin/sh
VAULT="$HOME/vault/Daily"
NOTE="$VAULT/$(date +%Y-%m-%d).md"
[ -f "$NOTE" ] || exit 0
jq -n --arg body "$(cat "$NOTE")" --arg date "$(date +%Y-%m-%d)" \
'{source: "obsidian daily note", date: $date, note: $body}' \
| curl -sS -X POST https://api.deariary.com/webhooks/ingest \
-H "Authorization: Bearer $DEARIARY_WEBHOOK_TOKEN" \
-H "Content-Type: application/json" \
--data-binary @-
Using jq to build the body matters more than it looks. Real markdown contains quotes, newlines, backticks and brackets, and hand-rolling JSON with echo breaks on the first file you actually wrote in.
Run it on a schedule (cron, launchd, systemd timer) once in the evening, before your generation time.
Triggering it from the editor
If you would rather push on demand than on a timer, the Shell commands community plugin runs system commands from the command palette or a hotkey, and exposes variables including the current file’s path. Point it at a script that takes a path argument:
#!/bin/sh
# usage: push-note.sh /path/to/note.md
jq -n --arg body "$(cat "$1")" --arg name "$(basename "$1")" \
'{source: "obsidian", note_name: $name, note: $body}' \
| curl -sS -X POST https://api.deariary.com/webhooks/ingest \
-H "Authorization: Bearer $DEARIARY_WEBHOOK_TOKEN" \
-H "Content-Type: application/json" \
--data-binary @-
Bind that to a hotkey and it becomes one keystroke. This is the better setup if you write up arbitrary days rather than only today.
The date gotcha
This is the part that will confuse you if nobody says it out loud.
The entry date is assigned from when the request arrives, in your timezone. Not from any date field in the payload. So text about Tuesday pushed on Wednesday morning attaches to Wednesday.
Two consequences worth planning around:
Run scheduled pushes in the evening, before the entry for that day is generated, not the next morning.
Include the date in the payload anyway, as in the examples above. It will not move which day the payload is filed under, but it does mean the text the model reads says which day it is talking about, which is better than nothing when you do push late.
If you habitually write up days after the fact, accept that payloads land on the day you typed them and treat the date field as the real signal.
Sending more than text
The webhook reads a few conventional field names for extra structure. Arrays named media, images, attachments or files with url fields become media on the entry. latitude and longitude (or lat and lng) become a location. An array called highlights with kind and title fields becomes highlight items.
For this bridge that means one thing: image links in the file can arrive as media rather than as raw markdown stranded mid-sentence. Pull the URLs out and send them as an images array.
jq -n --arg body "$(cat "$NOTE")" \
--argjson imgs "$(grep -o 'https://[^)]*\.\(png\|jpg\|jpeg\)' "$NOTE" | jq -R '{url: .}' | jq -s '.')" \
'{source: "obsidian daily note", note: $body, images: $imgs}'
What to actually send
The instinct is to push the entire file. Usually wrong.
A file in a mature setup carries task checkboxes, template scaffolding, wikilinks, dataview blocks and headers. None of that helps, and much of it competes with the real content for attention at generation time.
Better to send only the prose. If the template has a ## Log or ## Notes heading, slice that section out:
sed -n '/^## Log/,/^## /p' "$NOTE" | sed '1d;$d'
Meetings, commits, tasks, listening and places are already arriving through the normal integrations. What you typed adds the one layer no API exposes: what you were thinking while it happened.
Pushing more than once a day
Each POST is stored as its own artifact, so repeated pushes do not overwrite each other. Press the hotkey four times and four payloads get filed against that day, all of which are read at generation time.
That is convenient and it has an obvious failure mode. Pushing the same growing file at 10am, 2pm and 7pm sends the morning’s text three times, once per push, with the later copies as supersets. Nothing breaks, but you are spending payload budget on duplicates and giving the same sentences triple weight.
Two ways out. Either push once, late, and accept that a crash before then loses the day’s note. Or track a byte offset and send only the tail:
OFFSET_FILE="$HOME/.cache/deariary-offset-$(date +%F)"
OFFSET=$(cat "$OFFSET_FILE" 2>/dev/null || echo 0)
SIZE=$(wc -c < "$NOTE")
[ "$SIZE" -le "$OFFSET" ] && exit 0
tail -c +$((OFFSET + 1)) "$NOTE" > /tmp/note-delta.txt
printf '%s' "$SIZE" > "$OFFSET_FILE"
Then send /tmp/note-delta.txt as the body. This works because appending is how people actually write daily notes. It breaks if you edit earlier in the file, in which case the offset is wrong and you lose the edit. Choose based on whether you append or revise.
Limits worth being clear about
Advanced plan only. Webhook access is not on the lower tiers.
One-way. Nothing writes into your vault. There is an export from deariary, but no sync.
No file watching. Nothing here reacts to a save by itself. Either it is scheduled or you press the key.
100 KB per request. Plenty for one note, nowhere near a vault, and a vault is not the point.
Your text is read by a language model at generation time. If the file contains things you would not send to a third party, send an extracted section rather than the whole thing, or skip this entirely. The privacy post has the detail on how generation works.
What this actually buys
One thing, precisely. The prose you wrote lands in the same entry as the factual record of that day, so re-reading gives you both the outline and what you were thinking inside it.
Everything else the day contained is already arriving on its own. That is worth remembering before spending an evening on shell scripts: this bridge adds the interior. It does not add coverage, because coverage was never the missing part.