Omnidapter: one API over calendars, bookings and CRMs

Every tool we build for a small business eventually needs to reach into someone else's system. Read the owner's calendar before offering a time. Book the appointment in the scheduler they already use. Drop the new lead into their CRM. Each of those is a different provider, with its own login flow, its own idea of what an "event" is, and its own quirks, and supporting three of them means maintaining three integrations forever.

Omnidapter is our experiment in doing that once.

One API, three kinds of service

Omnidapter puts calendars, booking systems and CRMs behind a single, consistent model. You connect an account once, then ask the connection for the service you need:

from omnidapter import Omnidapter

omni = Omnidapter(
    credential_store=my_enc_store,
    oauth_state_store=my_redis_store,
)

# Calendar: list events from any provider
conn = await omni.connection("google_conn_1")
calendar = conn.calendar()
async for event in calendar.list_events("primary"):
    print(f"[{event.start}] {event.summary}")

The same code reads a Microsoft or Zoho calendar. Swap the connection, not the integration.

It covers eleven providers today:

Provider	Calendar	Booking	CRM
Google	yes
Microsoft	yes
Apple (iCloud)	yes
CalDAV	yes
Cal.com		yes
Square		yes
Calendly		partly
HubSpot			yes
Pipedrive			yes
Salesforce			yes
Zoho	yes	yes	yes

A single sign-in can authorize several services at once, so a business on Zoho connects one account and gets its calendar, bookings and CRM together.

Your users' tokens stay with you

The hosted integration platforms make a trade on your behalf: they hold your users' OAuth tokens, and you hold an ID that points at them. That is simpler to start with, and it means a third party is in the middle of every call and holds the keys to your customers' accounts.

Omnidapter takes the other side of that trade. Credential storage is an interface you implement. The tokens live in your database, encrypted however you choose, and never leave your infrastructure. It runs as a Python library inside your app, or as a self-hosted REST server with a generated client for everything else. More for you to operate, and nothing of your customers' held by us or anyone else.

Honest about what each provider can do

Providers do not agree on what they support. Calendly, for example, will tell you availability but will not let you create a booking through its API. Rather than let that surface as a failure halfway through a customer's booking, Omnidapter publishes capability flags per provider, so your code can ask whether an operation is supported before it relies on it.

How it was built

Omnidapter was written spec-first. Before code, each behaviour was pinned down in one of 47 written specifications: the domain model, auth, every service, every provider, the server and the SDK. The code was then built against those specs with Claude as a pair programmer. Of 658 commits between March and June 2026, 416 were co-authored with Claude.

That was the experiment: whether AI working from precise written specifications could produce an integration engine with real depth rather than a demo. The provider matrix above is the answer so far.

Try it

pip install omnidapter

It is published on PyPI under the MIT license.

If your business needs its tools to talk to each other and nothing off the shelf quite fits, get in touch.