Obsidian Stats logoObsidian Stats

Local REST API - Periodic Notes

by Adam Coddington
5
4
3
2
1
Score: 50/100
Install Code

Description

Periodic-note REST endpoints and MCP tooling for Obsidian Local REST API.

Reviews

No reviews yet.

Stats

3
stars
1,659
downloads
0
forks
53
days
52
days
53
days
0
total PRs
0
open PRs
0
closed PRs
0
merged PRs
0
total issues
0
open issues
0
closed issues
4
commits

Latest Version

1.0.0
2 months ago

Changelog

This is the companion plugin promised in Local REST API 5.0.2, which removed periodic-note support from the core plugin so it could drop its dependency on periodic-note plugin internals. It restores the /periodic/ REST endpoints and the periodic_note_get_path MCP tool using the host's public API extension interface, so the functionality returns without the dependency going back into the core.

Requires Local REST API providing extension API version 2 or later, plus the core Daily Notes plugin and/or the community Periodic Notes plugin configured for the periods you intend to use.

  • Adds /periodic/{period}/ and /periodic/{period}/{year}/{month}/{day}/ for GET, PUT, POST, PATCH, and DELETE, where {period} is one of daily, weekly, monthly, quarterly, or yearly. A trailing path segment targets a heading or block within the note, exactly as it does under /vault/.
  • Adds a periodic_note_get_path MCP tool returning the vault-relative path of the current periodic note for a period, creating the note if it does not exist.
  • Delegates all folder, format, template, and creation logic to the Daily Notes (core) and Periodic Notes (community) plugins via obsidian-daily-notes-interface, the same model Local REST API used before its since-removed native implementation. Configure periodic notes in those plugins; a period that is not enabled there returns 400.
  • Note for clients migrating from Local REST API 4.x: the periodic routes now resolve the target note and redirect (307) to the host's /vault/{path} endpoint rather than serving content inline, so content negotiation and write semantics stay identical to /vault/ and no host-private methods are reproduced here. Clients must follow redirects, which preserve the method, body, and headers.
See all version on GitHub

README file from

Github

Obsidian Local REST API — Periodic Notes

Adds periodic-note support to Obsidian Local REST API using functionality provided by @liamcaine's Periodic Notes plugin.

What it adds

Once both this plugin and Local REST API are enabled:

  • REST — /periodic/{period}/ and /periodic/{period}/{year}/{month}/{day}/ for GET, PUT, POST, PATCH, and DELETE, where {period} is one of daily, weekly, monthly, quarterly, or yearly. Read, create, append to, patch, or delete the current (or a dated) periodic note. A trailing path segment targets a heading or block within the note, exactly as it does under /vault/.
  • MCP — a periodic_note_get_path tool that returns the vault-relative path of the current periodic note for a period, creating it if necessary.

How it works

This plugin delegates all folder/format/template/creation logic to the core Daily Notes and community Periodic Notes plugins via obsidian-daily-notes-interface — the same model Local REST API used before its (since-removed) native implementation. Configure your periodic notes in those plugins; this plugin reads their configuration. A period that is not enabled in those plugins returns 400.

The REST routes resolve the target periodic note and then redirect (307) to the host's existing /vault/{path} endpoint, so content negotiation and write semantics stay identical to /vault/ and no host-private methods are reproduced here. See the design note in src/routes.ts for the trade-off this makes.

Requirements

Development

npm install
npm run dev        # watch build
npm run build      # production build
npm run typecheck  # tsc --noEmit
npm run lint       # eslint, including the obsidianmd plugin rules
npm test           # jest

Releases are cut by tagging: npm version <x.y.z> updates manifest.json and versions.json (via version-bump.mjs) and creates a bare tag, and pushing that tag runs .github/workflows/release.yml, which type-checks, tests, builds, attests, and publishes main.js and manifest.json to a GitHub release.

Sponsors