Kloudless shut down its public platform, and teams that built on it now need a new home for their email and calendar integrations. Unified.to picks up some of that demand with a single API spanning dozens of categories: CRM, HR, ticketing, accounting, storage, and messaging. The pitch is breadth. One contract, every SaaS app you might ever touch.
Breadth comes at a cost. When one API tries to cover 30 categories, the email and calendar surface ends up shallow: a normalized message object, a normalized event, and not much past that. If your product lives in email, calendar, and contacts, you want depth in those three things, not a thin slice of everything. This page compares the aggregator approach with a purpose-built communications API and is honest about when an aggregator is the better call.
Kloudless and Unified.to vs a purpose-built API
Section titled “Kloudless and Unified.to vs a purpose-built API”A purpose-built email and calendar API goes deep on a few providers instead of shallow across many categories. You read mail through GET /v3/grants/{grant_id}/messages, calendar through GET /v3/grants/{grant_id}/events, and contacts through GET /v3/grants/{grant_id}/contacts, all behind one OAuth grant. A broad aggregator like Unified.to normalizes the same objects but stops at the common denominator.
The split is depth versus breadth. Unified.to connects to 200-plus tools across categories, which is the right tool when you need a CRM and a payroll system and a help desk under one schema. It was never built to expose message threading, Free/Busy availability math, server-side webhooks per mailbox, or attachment upload sessions. Kloudless had the same shape before it sunset: an aggregator first, a communications API second. The table below maps the work an email and calendar integration actually requires.
| Capability | Aggregator (Kloudless / Unified.to) | Purpose-built unified API |
|---|---|---|
| Category focus | 30-plus categories, email shallow | Email, calendar, contacts in depth |
| Read mail | Normalized message object | GET /v3/grants/{grant_id}/messages |
| Calendar availability | Rarely exposed | POST /v3/grants/{grant_id}/calendars/free-busy |
| Real-time updates | Polling in most cases | /v3/webhooks with 13-plus event triggers |
| Email providers | Generic IMAP and a few OAuth apps | Google, Microsoft, Yahoo, iCloud, IMAP, Exchange |
What are the differences between Kloudless and other email and calendar API platforms?
Section titled “What are the differences between Kloudless and other email and calendar API platforms?”Kloudless was a multi-category aggregator that bundled email and calendar alongside storage, CRM, and other SaaS verticals, then sunset its public platform. The main difference from a communications-first API is depth: Kloudless normalized basic message and event objects, while a focused platform exposes threading, Free/Busy, scheduling, and per-mailbox webhooks that an aggregator rarely surfaces.
Three differences matter when you replace Kloudless. First, provider coverage on the email side: a purpose-built API connects Google, Microsoft, Yahoo, iCloud, IMAP, and Exchange through one grant, where aggregators often fall back to generic IMAP with no OAuth. Second, real-time data: the /v3/webhooks endpoint pushes message and event changes through 13-plus trigger types instead of forcing you to poll. Third, calendar math: POST /v3/grants/{grant_id}/calendars/free-busy returns busy blocks across attendees, which is exactly the primitive scheduling features need and aggregators almost never ship. If your Kloudless usage was email and calendar, depth in those areas is the whole point of switching.
How does a unified email and calendar API compare to integrating each provider separately?
Section titled “How does a unified email and calendar API compare to integrating each provider separately?”A unified API replaces three or more separate integrations with one schema and one OAuth flow. Instead of the Gmail API, Microsoft Graph, and a raw IMAP client, each with its own tokens, ID formats, and quotas, you call GET /v3/grants/{grant_id}/messages once and reach every connected provider. One grant currently spans 6 email providers, so adding iCloud after Google costs no new code.
Integrating providers separately gives you maximum control and zero abstraction overhead, and for a single-provider product that can be the right choice. The tradeoff is multiplied work: each provider brings a distinct auth model, a different message ID scheme, separate rate limits, and its own webhook renewal rules. Microsoft Graph subscriptions expire roughly every 3 days and need renewal; the unified layer holds one webhook subscription per app and handles the rest. The auth flow collapses too. You send users through /v3/connect/auth once, pick the provider at runtime, and exchange the code at /v3/connect/token. To see the multi-provider read pattern end to end, read sync messages across multiple providers.
What email and calendar integration APIs work well with Microsoft 365?
Section titled “What email and calendar integration APIs work well with Microsoft 365?”Microsoft 365 integration runs on OAuth through Microsoft Entra, since Microsoft deprecated basic authentication for all Exchange Online accounts on October 1, 2022. A unified API connects Microsoft 365 mailboxes with one connector and admin consent, then exposes the same GET /v3/grants/{grant_id}/messages and GET /v3/grants/{grant_id}/events calls used for Google and iCloud, so Microsoft is not a special case in your code.
Microsoft 365 is where aggregators and focused APIs diverge most. Outlook throttles hard: aggressive per-app, per-mailbox throttling that returns a 429 with a Retry-After header when you cross it. A depth-first API absorbs that throttling with retry handling and favors webhooks over polling, which a generic IMAP fallback cannot do because IMAP loses Microsoft’s native folder and category model. The connection itself uses standard delegated or application permissions, documented in the official Microsoft Graph throttling limits reference. If your roadmap is Microsoft-heavy with a Google tail, one schema across both beats stitching Graph and the Gmail API together by hand.
Reading email, calendar, and contacts through one grant
Section titled “Reading email, calendar, and contacts through one grant”The strongest reason to pick depth over breadth shows up in the request shape: one grant, three resources, one auth model. The call below lists messages from any connected provider through GET /v3/grants/{grant_id}/messages. Set limit to 20 on high-volume mailboxes to avoid the 429 rate-limit responses Outlook and Gmail return under load.
curl --request GET \ --url 'https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/messages?limit=20' \ --header 'Authorization: Bearer <NYLAS_API_KEY>'Calendar availability is the primitive aggregators skip and scheduling products depend on. The request below posts to POST /v3/grants/{grant_id}/calendars/free-busy and returns busy time blocks for one or more email addresses, so you compute open slots without reading every event. It accepts a start_time and end_time as Unix timestamps and a list of emails.
curl --request POST \ --url 'https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/calendars/free-busy' \ --header 'Authorization: Bearer <NYLAS_API_KEY>' \ --header 'Content-Type: application/json' \ --data '{ "start_time": 1700000000, "end_time": 1700086400, "emails": ["[email protected]"] }'Contacts complete the set. The same grant reads address-book entries through GET /v3/grants/{grant_id}/contacts, returning names, email addresses, and phone numbers in the same JSON shape across providers. For the full contacts read, filter, and write flow, see the contacts API guide.
When should you keep an aggregator like Unified.to?
Section titled “When should you keep an aggregator like Unified.to?”Keep a broad aggregator when your integration footprint spans many SaaS categories beyond communications. If your product needs to sync a CRM, a payroll system, an accounting ledger, and a ticketing tool under one contract, Unified.to’s 200-plus connectors across 30-plus categories solve a problem no email-focused API addresses. Breadth is genuinely the right call there.
Pick the purpose-built API when email, calendar, and contacts are the product, not a side feature. A scheduling tool needs Free/Busy math, a CRM sync needs reliable contact and thread data, and an inbox feature needs per-mailbox webhooks, none of which an aggregator exposes at depth. If two of your three core objects are communications data, a purpose-built API wins on every axis that matters: provider coverage, real-time updates, and the specific endpoints scheduling and email features require. A reasonable middle ground exists too: use the aggregator for the long tail of business apps and a focused API for the communications core, since the two solve different halves of the problem.
What’s next
Section titled “What’s next”- Sync messages across multiple providers for the unified read pattern across Google, Microsoft, and IMAP
- Microsoft Graph API alternative for the deep Microsoft 365 comparison
- Contacts API guide to read and manage address-book data through one grant
- Getting started with Nylas to create a project, connector, and your first grant