diff --git a/apps/web/content/docs/compare/cronofy.mdx b/apps/web/content/docs/compare/cronofy.mdx new file mode 100644 index 0000000..e0f9fb6 --- /dev/null +++ b/apps/web/content/docs/compare/cronofy.mdx @@ -0,0 +1,67 @@ +--- +title: calsdk vs Cronofy +description: An open source alternative to the Cronofy calendar API. How a hosted sync service and a library differ in cost, data and features. +--- + +Cronofy is a hosted calendar service. Your users connect their calendars to Cronofy, Cronofy keeps a synced copy of their events, and your app reads and writes through Cronofy's API. calsdk is a library that runs inside your app and calls Google, Microsoft, iCloud and the others directly, with tokens your app holds. There's no copy of anyone's calendar on a third-party server, and no monthly bill. + +## Side by side + +| | Cronofy | calsdk | +| ----------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------ | +| What it is | Hosted API with its own synced copy of each calendar | Open source TypeScript library (MIT) | +| Price | From $819 a month for 500 accounts | Free | +| Calendars | Google, Microsoft 365, Outlook.com, Exchange, iCloud | Google, Microsoft, iCloud, Zoho, any CalDAV server, Zoom, Cal.com, Calendly, ICS feeds | +| Calendar data | Stored by Cronofy, 42 days back to 201 days ahead | Not stored anywhere but your app, if you choose to | +| OAuth | Users authorize Cronofy; your app holds Cronofy tokens | Your app holds the provider tokens | +| Change notifications | Push notification channels | Incremental [sync](/docs/guides/sync) you run on a schedule | +| Availability | Multi-person and sequenced availability API | [findFreeTime](/docs/guides/free-time) across any mix of providers | +| Scheduling UI | UI Elements and an embeddable scheduler | None | +| Languages | .NET, PHP, Ruby, Python and Node SDKs | TypeScript and JavaScript only | + +Cronofy prices and features are from [cronofy.com/pricing](https://www.cronofy.com/pricing) and the [Cronofy docs](https://docs.cronofy.com/developers/), checked in November 2026. + +## What it costs + +Cronofy's API plans start with Emerging at $819 a month on annual billing ($899 month to month), which includes 500 synced accounts, then $1.39 for each one after that. Growth is $2,399 a month for 3,000 accounts. There's a free trial but no free production plan. + +For an app with 1,000 connected users, that's about $1,500 a month on Emerging. For an app with 50 users, it's still $819, which is often the deciding factor for a small product where calendars are one feature among many. + +calsdk costs nothing. The provider APIs it calls are free within their quotas. + +## Where your users' data goes + +Cronofy's model is a synced copy. Its docs say it stores event information for a window from 42 days in the past to 201 days ahead, and reads are limited to that window unless you ask support to extend it. Data lives in the data center you pick (US, UK, Germany, Canada, Australia or Singapore), and each one is a separate account. + +Because users authorize Cronofy rather than your app, your app holds Cronofy's tokens, not Google's or Microsoft's. If you ever move off Cronofy, your users have to connect their calendars again. + +With calsdk, your app holds the provider tokens and talks to the provider directly. If you want a local copy, [syncEvents](/docs/guides/sync) keeps one in your own database, with whatever window you like. + +## When Cronofy is the better choice + +Cronofy does a lot that calsdk doesn't. Pick it if you want a hosted scheduling UI, sequenced availability (book an interviewer, then a second one straight after), meeting rooms, or push notifications without running your own sync job. Pick it for its compliance paperwork (ISO 27001, SOC 2, HIPAA) if a buyer asks for a vendor that has it. And pick it if your backend isn't JavaScript. + +## When calsdk fits better + +calsdk fits when calendars are a feature of your app rather than the product, and $819 a month before your first user doesn't make sense. It fits when you'd rather not add a vendor that stores your users' calendars, when you need Zoho, Fastmail, Nextcloud, Cal.com or Calendly, and when your app already has the user's Google or Microsoft token from sign in. + +Here's free time across two providers, the core of most scheduling features: + +```ts +import { findFreeTime } from '@cal-sdk/core'; +import { google } from '@cal-sdk/google'; +import { microsoft } from '@cal-sdk/microsoft'; + +const { slots } = await findFreeTime({ + calendars: [ + { calendar: google({ accessToken: hostToken }) }, + { calendar: microsoft({ accessToken: guestToken }) }, + ], + timeMin: new Date(), + timeMax: new Date(Date.now() + 7 * 86_400_000), + duration: 30, + workingHours: { start: '09:00', end: '17:00', timeZone: 'Europe/London' }, +}); +``` + +[Install calsdk](/docs/installation) or try it without an account in the [quickstart](/docs/quickstart). diff --git a/apps/web/content/docs/compare/meta.json b/apps/web/content/docs/compare/meta.json new file mode 100644 index 0000000..c0d5720 --- /dev/null +++ b/apps/web/content/docs/compare/meta.json @@ -0,0 +1,4 @@ +{ + "title": "Compare", + "pages": ["nylas", "cronofy", "unified-to"] +} diff --git a/apps/web/content/docs/compare/nylas.mdx b/apps/web/content/docs/compare/nylas.mdx new file mode 100644 index 0000000..75d8efb --- /dev/null +++ b/apps/web/content/docs/compare/nylas.mdx @@ -0,0 +1,63 @@ +--- +title: calsdk vs Nylas +description: An open source alternative to the Nylas Calendar API. What each one does, what each costs, and when to pick which. +--- + +Nylas is a hosted API: your app calls Nylas, and Nylas talks to Google, Microsoft and iCloud for you. calsdk is a library: it runs inside your app and talks to those providers directly, with tokens your app already holds. Both give you one event shape across calendars. The difference is where the integration runs, what you pay for it, and what you still have to build yourself. + +## Side by side + +| | Nylas | calsdk | +| ----------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------ | +| What it is | Hosted API | Open source TypeScript library (MIT) | +| Price | Per connected account, from $1.35 to $2.25 a month | Free | +| Calendars | Google, Microsoft, iCloud, Exchange (EWS) | Google, Microsoft, iCloud, Zoho, any CalDAV server, Zoom, Cal.com, Calendly, ICS feeds | +| Where requests go | Your app, then Nylas, then the provider | Your app, then the provider | +| OAuth and token refresh | Hosted for you, or bring your own | Your app's job | +| Change notifications | Webhooks | Incremental [sync](/docs/guides/sync) you run on a schedule | +| Free/busy | Google and Microsoft; not iCloud | Every provider, computed from events where there's no endpoint | +| Scheduling UI | Hosted Scheduler and components | None; [findFreeTime](/docs/guides/free-time) gives you the slots | +| Languages | Node.js, Python, Ruby, Kotlin and Java SDKs | TypeScript and JavaScript only | +| Email and contacts | Yes | No, calendars only | + +Nylas prices and features are from [nylas.com/pricing](https://www.nylas.com/pricing/) and the [Nylas calendar docs](https://developer.nylas.com/docs/v3/calendar/), checked in November 2026. + +## What it costs + +Nylas charges per connected account every month. Calendar-only accounts are not included on the free plan. On Essentials ($15 a month) each one past the first 10 costs $1.70, and on Pro ($49 a month, or $43 on an annual commitment) each one past the first 35 costs $1.50, or $1.35 on the annual plan. + +So an app with 1,000 users who each connect one calendar pays about $1,500 a month on Pro Monthly, or about $1,350 on Pro Annual. That number grows with your user count, not with how much your users do. + +calsdk has no price. You pay for the servers your app already runs on, and the provider APIs themselves are free within their quotas. + +## Where your users' data goes + +With Nylas, every calendar request passes through Nylas's servers in the region you chose (US or EU). Nylas says v3 forwards requests to the provider rather than storing calendar data, but the traffic, and the tokens if you use hosted auth, still go through a third party. Object ids are tied to that region, so moving regions means your users connect again. + +With calsdk there is no third party. Requests go from your server straight to Google or Microsoft, and the tokens never leave your app. For some teams that's the whole reason: one less vendor in a security review, one less place calendar data passes through. + +## When Nylas is the better choice + +Pick Nylas if you'd rather not run OAuth yourself. Google's sensitive calendar scopes need a verified app, and Nylas can take that on for you on higher plans. Pick it if you need webhooks today, a ready-made scheduling page, Exchange servers reached over EWS, or email and contacts alongside calendars. And pick it if your backend isn't JavaScript: calsdk only runs where TypeScript or JavaScript does. + +## When calsdk fits better + +calsdk fits when your app already signs users in with Google or Microsoft, so it already has the tokens, and you want the calendar features without a per-user bill. It also fits when you need calendars Nylas doesn't cover, like Fastmail, Nextcloud, Zoho, Cal.com or Calendly. And when you want your calendar code testable offline, the [mock provider](/docs/providers/mock) runs the same functions in memory. + +## Moving from Nylas + +Most of a Nylas integration maps directly. A Nylas grant becomes a provider you create with the user's token, and each events endpoint becomes a function: + +```ts +import { createEvent, findFreeTime, listEvents } from '@cal-sdk/core'; +import { google } from '@cal-sdk/google'; + +// Where Nylas had a grant id, you pass the user's own token. +const calendar = google({ accessToken: () => getFreshAccessToken(userId) }); + +const { events } = await listEvents({ calendar, timeMin, timeMax }); +``` + +The two pieces you'd build yourself are the OAuth flow (most auth libraries, such as Auth.js or Better Auth, already store Google and Microsoft tokens) and the webhook replacement, which is a scheduled [sync](/docs/guides/sync) per calendar. + +[Install calsdk](/docs/installation) or try it without an account in the [quickstart](/docs/quickstart). diff --git a/apps/web/content/docs/compare/unified-to.mdx b/apps/web/content/docs/compare/unified-to.mdx new file mode 100644 index 0000000..d188536 --- /dev/null +++ b/apps/web/content/docs/compare/unified-to.mdx @@ -0,0 +1,51 @@ +--- +title: calsdk vs Unified.to +description: An open source alternative to the Unified.to calendar API. A hosted unified API and a library compared on cost, coverage and data. +--- + +Unified.to is a hosted unified API that covers many categories, calendars among them. Your app calls Unified.to, and it calls the calendar provider live, without keeping a copy. calsdk does the calendar part as a library: it runs in your app and calls the providers directly, with tokens your app holds. Both normalize events across providers. The difference is the hop through a vendor, and the bill that comes with it. + +## Side by side + +| | Unified.to | calsdk | +| ----------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------ | +| What it is | Hosted unified API, calendars are one category of many | Open source TypeScript library (MIT), calendars only | +| Price | Per API call, from $750 a month for production | Free | +| Calendars | Google, Outlook, Exchange, iCloud, Zoom, Calendly, Cal.com, Zoho and others | Google, Microsoft, iCloud, Zoho, any CalDAV server, Zoom, Cal.com, Calendly, ICS feeds | +| Where requests go | Your app, then Unified.to, then the provider | Your app, then the provider | +| OAuth | Embeddable authorization component | Your app's job | +| Change notifications | Native webhooks, or polled "virtual" webhooks | Incremental [sync](/docs/guides/sync) you run on a schedule | +| Free/busy | A busy object per integration | [findFreeTime](/docs/guides/free-time) across any mix of providers | +| Languages | TypeScript, Python, PHP, Java, C#, Ruby and Go SDKs | TypeScript and JavaScript only | + +Unified.to prices and features are from [unified.to/pricing](https://unified.to/pricing) and [unified.to/calendar](https://unified.to/calendar), checked in November 2026. + +## What it costs + +Unified.to bills by API volume rather than by connected account, with unlimited connections. The free Test plan is for non-production use. Production starts with Grow at $750 a month for 750,000 calls, then $1 per 1,000 calls, and goes up to Scale at $3,000 a month. + +That model is friendly if you have many users who each make few calls. It's less friendly for calendars, where a sync job or a free-time search makes several calls per user every few minutes. + +calsdk costs nothing, and provider APIs are free within their quotas. + +## Where your users' data goes + +Unified.to says it never stores end-customer data and that every request hits the provider live, with no caching. That's a better position than a service that keeps a copy, but every request still passes through Unified.to's servers (US, EU or AU). With calsdk there's no middle hop: your server calls Google or Microsoft directly. + +## When Unified.to is the better choice + +Pick Unified.to if you need many categories at once, say a CRM, an ATS and calendars, behind one vendor and one auth component. Pick it if your backend is in Go, Java or C#, or if you want webhooks without writing a sync job. + +## When calsdk fits better + +calsdk fits when calendars are what you need, and you want them deep rather than broad. It handles recurring series with per-occurrence edits and "this and following" where the provider supports it, free time that fails closed instead of guessing, and sync with a stored cursor, with typed warnings whenever a provider can't do exactly what you asked. It also fits when $750 a month doesn't make sense for one feature, and when you'd rather your users' calendar traffic not pass through a third party. + +```ts +import { listEvents } from '@cal-sdk/core'; +import { icloud } from '@cal-sdk/caldav'; + +const calendar = icloud({ appleId, appPassword }); +const { events } = await listEvents({ calendar, timeMin, timeMax }); +``` + +[Install calsdk](/docs/installation) or try it without an account in the [quickstart](/docs/quickstart). diff --git a/apps/web/content/docs/faq.mdx b/apps/web/content/docs/faq.mdx index 7b37f0d..ca640fb 100644 --- a/apps/web/content/docs/faq.mdx +++ b/apps/web/content/docs/faq.mdx @@ -13,7 +13,7 @@ Google Calendar, Microsoft Outlook and Microsoft 365, iCloud, Zoho Calendar and ## Is calsdk a hosted service like Nylas or Cronofy? -No. Hosted calendar APIs run the integration on their own servers: your app calls their API, and they hold the connection to each calendar. calsdk is a library that runs inside your app and calls Google, Microsoft and the others directly, with tokens your app passes in. It has no server, database or queue of its own, so your users' calendar data doesn't pass through anyone else. +No. Hosted calendar APIs run the integration on their own servers: your app calls their API, and they hold the connection to each calendar. calsdk is a library that runs inside your app and calls Google, Microsoft and the others directly, with tokens your app passes in. It has no server, database or queue of its own, so your users' calendar data doesn't pass through anyone else. See how it compares with [Nylas](/docs/compare/nylas), [Cronofy](/docs/compare/cronofy) and [Unified.to](/docs/compare/unified-to). ## Does calsdk handle OAuth? diff --git a/apps/web/content/docs/meta.json b/apps/web/content/docs/meta.json index fd8077c..f384933 100644 --- a/apps/web/content/docs/meta.json +++ b/apps/web/content/docs/meta.json @@ -14,6 +14,8 @@ "...concepts", "---Reference---", "...reference", + "---Compare---", + "...compare", "---Build a provider---", "...build-a-provider" ]