Share calendar availability with outside tools — without handing over your calendars.
Runs in your own infrastructure. You decide what each tool may see.
Quickstart · How it works · API · Deployment · Security
Your team wants to use a scheduling tool. The scheduling tool wants to connect to Outlook. And that's where it stops for months.
Because letting an external vendor into your tenant means a DPA, a vendor security review, a DPIA, a works-council conversation and an architecture-board slot — for a feature whose entire job is to figure out when people are free.
FreebusyBridge removes the vendor from that equation.
Your IT team deploys one container inside your own infrastructure and connects it to Microsoft 365 using your own Azure app registration — the consent never leaves your tenant, and Microsoft itself restricts it to the mailboxes you name. You then decide, per external tool, exactly what it may see: free/busy only, or titles too; read-only, or allowed to book; these calendars, not those. The scheduling tool gets an API key and a narrow API. It never touches your calendar backend, and it never sees what it wasn't granted.
Your scheduling tool needs to know when people are busy — not what they are doing. FreebusyBridge enforces that boundary technically, inside your network, with an audit log.
The compliance question changes shape entirely. Instead of "can we allow this vendor into our calendars?" it becomes "we run this ourselves, here's the audit log."
- 🔒 Microsoft consent never leaves your tenant. Your admin creates your own app registration; access is limited to selected mailboxes via Exchange
ApplicationAccessPolicy— enforced by Microsoft, not by a vendor's promise. - 🎛️ You decide what's exposed, per consumer. Free/busy only (titles are never even requested from Graph) or titles; read-only or booking allowed; which calendars. Changeable and revocable at any time, in a web UI.
- 📋 Everything is audited. Every consumer request is logged: endpoint, calendars, field classes, status. When someone asks what the vendor actually accessed, you have the answer.
- 📦 One container. SQLite by default, Postgres if you want it. No message broker, no sidecar, no cluster. If a compliance problem just becomes an IT problem, it isn't solved — so this stays boring to run.
- 🔍 Small enough to actually review. Lean dependency policy, AGPL-3.0, and a rigid OpenAPI contract your security team can read in an afternoon.
┌──────────────────┐ ┌───────────────────────────┐ ┌──────────────────┐
│ Microsoft 365 │ │ FreebusyBridge │ │ meetergo & co. │
│ │◄────────►│ │◄────────►│ │
│ your own app │ Graph │ policy filter · audit │ API key │ free/busy only │
│ registration │ │ log · booking │ /v1 │ no titles │
└──────────────────┘ └───────────────────────────┘ └──────────────────┘
your tenant your infrastructure the vendor
- IT deploys it — one container, in your network, on your terms.
- IT connects Microsoft 365 — your own app registration, scoped by Exchange to just the mailboxes that should be reachable (~15 min, walkthrough here).
- You add a consumer — issue an API key to your scheduling tool and set its policy.
- The tool asks for availability — and gets exactly what the policy allows, nothing more, with every request in the log.
| Setup wizard — connect M365 with your app registration | Consumer policy — free/busy vs titles, booking on/off, per-calendar allowlist |
| Show-once API key — hashed at rest, revocable | Access log — every consumer request, field classes included |
And the boundary at work: adding a mailbox outside your ApplicationAccessPolicy is denied by Microsoft itself — FreebusyBridge surfaces it, it doesn't decide it.
docker compose -f deploy/docker-compose.yml up -d
# open http://localhost:8080/admin/ → first-run wizard- Create the admin account.
- Connect Microsoft 365 — docs/azure-setup.md walks through the app registration + mailbox-scoping PowerShell (~15 min).
- Add mailboxes, create a consumer (e.g. meetergo), set its policy, issue an API key.
Kubernetes/Helm and configuration reference: docs/deployment.md. Security model and threat boundaries: docs/security.md.
A rigid, versioned OpenAPI 3.1 contract: api/openapi.yaml (generated from the code, drift-checked in CI, served at /v1/openapi.json). Typed TS client in libs/api-client.
| Endpoint | What it does |
|---|---|
POST /v1/free-busy |
Busy intervals; titles only if policy allows. Failures are explicit (502) — never a silent "all free" |
GET /v1/calendars |
Opaque calendar ids; provider ids never leak |
POST/PATCH/DELETE /v1/calendars/{id}/events |
Booking with idempotency keys — safe retries, even across "created but response lost" |
POST/GET/DELETE /v1/subscriptions |
Change notifications: subscribe once, FreebusyBridge keeps the Microsoft-side watches alive and POSTs every change to your endpoint, with retries and a dead-letter queue. Falls back to delta polling where Microsoft can't reach your deployment |
GET /v1/meta |
Capabilities, plus the caller's own effective policy |
Microsoft 365 is available today, with the full feature set: free/busy, booking, change notifications and audit logging.
Google Workspace, CalDAV and on-prem Exchange (EWS) are coming next, along with delegated per-user OAuth. Every provider plugs in behind the same /v1 contract — whatever you connect, the tools you integrate with keep talking to the identical API, and your policies keep working unchanged.
Also on the way: Nextcloud App Store (External App), openCode.de listing, and an SBOM/signing pipeline.
Bug reports, provider implementations and deployment recipes are all welcome — see CONTRIBUTING.md for the dev setup, the repo layout and the test approach (Microsoft Graph is faked in-process, so the full suite runs offline). Security issues: SECURITY.md.
pnpm install
pnpm -r test # unit + contract tests, no tenant requiredAGPL-3.0-only. Deploying FreebusyBridge unmodified inside your organization imposes no obligations beyond the license text; the copyleft exists to keep hosted derivatives open.
Developed by meetergo — and free for everyone to self-host.