Slotly
Sign inStart free

Documentation

Docs for humans, not lawyers.

Slotly is small enough that the docs fit on one page. Pick a topic.

Getting started

Sign up, set your time zone, create your first event type, share the link.

Availability

Define weekly working hours. Mark windows Ideal or Backup to control ranking.

Event types

Create booking links: title, duration, buffer time, description, custom slug.

Smart Overlay

How guests overlay their busy blocks on your calendar to find mutual openings.

Ranked Availability

Why marking some windows Backup helps you protect the hours you really want.

Time zones

How Slotly handles DST, ambiguous times, and guest-side TZ detection.

API reference

REST endpoints for slots and bookings. Coming Q3 2026.

Zapier and Make

No-code recipes for webhooks, sheets, CRMs, Slack, and API actions.

Launch checklist

Production smoke tests, OAuth redirects, email verification, and final manual QA.

Getting started

  1. Sign up at getslotly.io.
  2. Confirm your email when the message lands.
  3. You'll land on the dashboard. Set your time zone under Availability.
  4. Mark which days you're Ideal vs Backup.
  5. Create your first event type — a 30-minute sync is a good starter.
  6. Copy the share link (it'll be on the slotly.to domain). Send it.

Availability

Set weekly working hours per day. You can disable any day entirely. Each enabled day has a single window for now (e.g. 9am–5pm) plus a priority toggle: Ideal for hours you want front-of-line, Backup for "I'd rather not, but I'll take it if I have to."

Smart Overlay

On the public booking page, guests can toggle Overlay my calendar to compare the host's availability against their own busy blocks. Guests can import an exported .icscalendar file directly in the browser; Slotly uses those events to hide conflicting times and highlight slots that work for both sides. If no file is imported, the page can still show sample busy blocks for a quick demo.

Time zones

Slotly stores all bookings in UTC. The slot engine converts your host-local availability windows to UTC for storage, then back to guest-local time for display via date-fns-tz. Daylight saving transitions are handled correctly — the engine re-evaluates the offset for the actual calendar date being requested, not the offset at server start.