Two ways to integrate
Publish — for on-device apps
Your app runs on the same Mac as Meradomo. On launch it calls the local management API
(
POST 127.0.0.1:8765/publish) and — once the owner approves — becomes reachable at its own
address. Every request arrives with verified X-Meradomo-* identity headers. No sign-in code.Connect — for remote clients
Your app has its own mobile app, CLI, or web client that talks to the user’s Meradomo from
elsewhere. Use “Connect with Meradomo” (OAuth 2.0 + PKCE) to obtain an access token the agent
validates on every request — with refresh-token rotation and one-tap revocation.
Most apps only need Publish. Reach for Connect when you also ship a separate client (native
app or CLI) that connects into the user’s Meradomo from another device.
The addressing model
- The user has a root address,
you.meradomo.com(their chosen short name). - Each app you publish gets its own address — a full host, not a path:
app.you.meradomo.com(e.g.notes.you.meradomo.com). Your app lives at the root of that host, so all your root-relative asset and API paths just work unmodified. - Publishing a new app provisions no new certificate — one wildcard covers every app under the
user’s namespace (
*.you.meradomo.com). Adding apps is instant.
What your app can trust
On every request that reaches your published app, Meradomo injects verified, non-forgeable headers:| Header | Value |
|---|---|
X-Meradomo-User | Stable, unique id for the signed-in person |
X-Meradomo-Email | Their verified email address |
X-Meradomo-Name | The owner’s short name |
X-Meradomo-App | Your published app’s label |
Start here
Quickstart
Publish a sample app and reach it remotely in ~10 minutes.
Sample apps
Two runnable, MIT-licensed examples — one Publish, one Connect.
There is intentionally no SDK in v1 — the local management API and the OAuth endpoints are the
integration surface, and the two samples are the reference implementations. Everything you need is a
plain HTTP call.