OnSched vs Nylas: Scheduling API Comparison

Command references used in this guide: nylas calendar availability check, nylas calendar events create, and nylas calendar events list.

What is the difference between OnSched and Nylas?

OnSched is white-label booking infrastructure: appointments, resources, services, and locations live in OnSched's own database, and the company reports more than 22 million appointments scheduled through it. Nylas is a calendar API: it connects to a user's real Google or Outlook calendar over OAuth and exposes events, availability, and free/busy as raw data.

OnSched bills itself as a “mission-critical scheduling API for your app or marketplace” on onsched.com, and its API docs describe an object model built for service businesses — the company says it handled roughly 80% of Canada's COVID vaccine appointment bookings. Nylas sits a layer lower: instead of hosting a booking system, it gives your code direct read/write access to the calendars people already use, via the Google Calendar API and Microsoft Graph behind one interface. The Nylas CLI wraps that same API for the terminal, which is why every example below runs without writing a line of application code.

How do booking flows differ between OnSched and Nylas?

An OnSched booking flow walks a fixed object model: create a location, a resource, and a service, query availability for that service, then post an appointment — all stored in OnSched's system and synced out to Google or Outlook. A Nylas booking flow writes an event straight onto the participant's own calendar, so the provider stays the system of record.

That object model is OnSched's strength for marketplaces. Its v3 API (currently v3.7.1-stable) ships round-robin assignment, group bookings with max capacity, custom booking fields, and SMS confirmations as configuration, not code. Nylas has no booking objects at all: you get calendars, events, and participants, and you decide what a “booking” means in your product. The trade-off: every OnSched object is one more record to reconcile when a provider edits their calendar directly.

How do the availability endpoints compare?

OnSched computes availability from rules you configure: operating hours, weekly allocations, and booking limits feed a per-service availability endpoint. Nylas computes availability from reality — it reads free/busy from each participant's connected calendar, so a dentist's blocked lunch hour or a recruiter's existing call removes those slots without anyone updating a rules table.

The two models fail differently. Rule-based availability drifts when real calendars change outside the booking system; calendar-based availability requires every bookable person to connect a calendar. The CLI lets you test the Nylas model before writing code: nylas calendar availability find searches for slots when all participants are free, defaulting to 30-minute meetings at 15-minute intervals over the next 7 days. Both subcommands accept a --json flag, so the same output that prints in your terminal can feed a prototype booking UI or a cron job with no SDK involved.

# Find 30-minute slots all participants can make
nylas calendar availability find \
  --participants alice@example.com,bob@example.com \
  --duration 30 --interval 15 --json

# Inspect raw free/busy for the next day
nylas calendar availability check --duration 1d

When should you buy OnSched instead of building on Nylas?

Buy OnSched when bookings are your product's inventory: a marketplace of 50 clinics with rotating staff needs locations, resources, round-robin, and HIPAA-aligned infrastructure on day one, and OnSched ships all of that as configuration. Build on Nylas when scheduling is one feature inside your app and the user's own calendar must stay the source of truth. In regulated verticals, OnSched's HIPAA-aligned and SOC 2 posture also saves a compliance build that can take a quarter on its own.

Here's the calendar-of-record question the TL;DR promised: who owns the calendar your availability comes from? If the answer is “your platform,” where providers log into your dashboard to set hours, OnSched's model fits. If the answer is “each user's existing Google or Outlook account,” you need calendar-level access, and a booking layer becomes a second database to keep in sync. A CRM adding meeting scheduling for 1,000 sales reps shouldn't ask each rep to maintain hours in a separate system when their calendar already knows.

How do I prototype a booking flow with the Nylas CLI?

A minimal booking flow on Nylas is two commands: find a free slot, then create the event with participants. The CLI runs both against a connected Google or Outlook account, so you can validate the whole loop in under 5 minutes before committing to an SDK. Install with brew install nylas/nylas-cli/nylas (other methods are in the getting started guide). That's the entire surface a booking feature needs: read availability, write an event, list what exists.

The nylas calendar events create command writes the event to the provider calendar and invites participants, which generates a standard iCalendar invite per RFC 5545. The attendee gets a native invite in their inbox, with no booking-page redirect involved. When plans change, nylas calendar events update reschedules the same event in place, and the participant's copy follows because the provider calendar is the source.

# 1. Find a slot that works for both sides
nylas calendar availability find \
  --participants alice@example.com --duration 30 --json

# 2. Book it directly on the real calendar
nylas calendar events create \
  --title "Intro call" \
  --start "2026-06-12 14:00" --end "2026-06-12 14:30" \
  --participant "alice@example.com"

# 3. Confirm it landed
nylas calendar events list --days 7

Next steps

• Cal.com vs Nylas — open-source scheduling product vs calendar API
• Developer scheduling without Calendly — build booking on the calendar API
• SavvyCal vs Nylas — scheduling links vs scheduling infrastructure
• Acuity Scheduling API alternative — another booking product compared with the API route
• Kloudless alternative — unified calendar API options after a shutdown
• Check calendar availability from the CLI — free/busy and slot-finding in depth
• Full command reference — every flag and subcommand documented