CalendarPipe REST API
Pro plan. API access requires a Pro plan. View plans.
CalendarPipe has a public REST API at https://www.calendarpipe.com/api/v1. Every endpoint, parameter, and response shape is in the API Reference — generated from the API itself, so it cannot fall out of date. Start there for anything about a specific request.
The pages in this section cover what a generated reference cannot: how to get a key, what the errors mean, and the behaviour behind a few flows that span several endpoints.
Machine-readable entry points
Everything an agent or a code generator needs sits at a fixed URL:
| Resource | URL |
|---|---|
| OpenAPI 3.1 description | https://www.calendarpipe.com/openapi.json (also /api/v1/openapi.json) |
| API catalog (RFC 9727) | https://www.calendarpipe.com/.well-known/api-catalog |
| Protected resource metadata (RFC 9728) | https://www.calendarpipe.com/.well-known/oauth-protected-resource |
| Site index for LLMs | https://www.calendarpipe.com/llms.txt |
| Full docs text | https://docs.calendarpipe.com/llms-full.txt |
| Agent skills | Agent skills |
The OpenAPI document names the scope each operation
requires under its security entry, and lists every scope with a description under
components.securitySchemes.bearerAuth. The same scope names appear as
scopes_supported in the RFC 9728 metadata, which is where a client that only
speaks OAuth conventions will look for them. Every 4xx and 5xx response is
typed as the ApiError schema — see Errors.
Every page on www.calendarpipe.com also answers Accept: text/markdown with a Markdown
representation of itself — or append .md to the path. Each HTML page advertises its
Markdown twin in a Link: rel="alternate" header, and the Markdown representation
carries Vary: Accept.
What the API covers
| Resource | What you can do |
|---|---|
| Hosted calendars | Create, update, and delete calendars that live entirely in CalendarPipe, each with its own email address and .ics feed |
| Events | Read, create, update, delete, and cancel events on any calendar you have connected |
| Invitations | Send invitations, receive them, and RSVP — over polling or webhooks |
| Sync rules | The full lifecycle: create a rule, test its gate against your real events, enable it, force a re-sync, delete it |
Addressing a calendar
GET /api/v1/calendars returns an id for every calendar you can address. Pass that
value straight back to the event endpoints — it is already in the right form:
| Calendar | Looks like |
|---|---|
| Google, Microsoft | <accountId>:<providerCalendarId> |
| Apple | <accountId>:<caldavCalendarUrl> |
| Hosted | hosted:<id> |
| ICS feed | ics:<id> |
When reading, Google and Microsoft let you shorten the reference to a bare
<accountId>, meaning "the account's default calendar". Apple has no default calendar,
so a bare account id names nothing there and is rejected — pass the full reference. For
the same reason, GET /api/v1/events without calendarIds covers your Google and
Microsoft default calendars, every hosted calendar, and every ICS feed, but reads an
Apple calendar only when you name it.
When writing — creating, updating or deleting — always pass the full reference. A
bare account id is rejected with 400, because it says which account to write to but
not which of its calendars, and guessing would put your event somewhere you did not ask
for. Apple events are the one exception: they are addressed by the event id itself, so
the account id alone is enough to update or delete one.
To change or delete an event, pass the id from the event itself — not
providerEventId, which reports what the provider calls the event and is
informational.
What still needs the dashboard
Four things have no API equivalent, because each one needs a person:
- Connecting a Google, Microsoft, or Apple account — an OAuth consent flow.
- Adding a subscribed ICS feed.
- Creating an API key — see API Keys.
- Changing your plan.
Once your calendars are connected, everything else is available over the API. Sync rules included — you never have to open the dashboard to build, test, or change one.
Getting started
- Connect at least one calendar in the dashboard.
- Create an API key.
- Call
GET /api/v1/calendarsto see what you can address, then work from the API Reference.
Before you build against it, Versioning and deprecation says what can change and how much notice you get.