Availability
Calculate candidate times from a window and supplied busy intervals.
Set your availability, decide who can book, and choose how people reach you. Build on reusable scheduling and calendar functions, then make the rules and interface yours.
Calculate candidate times from a window and supplied busy intervals.
Decide which requests may be accepted, refused, or changed.
Test whether a requested time collides with existing events.
Read or write within the host permissions the owner approved.
Receive the proposal by email, messenger, platform, your own site, or Beacon.
The last part is transport. A verified booking rule does not depend on Beacon. Email can carry an invitation and a person can accept or decline it later; a connected agent can answer sooner. Beacon explores one shared point that could receive a proposal while the owner is offline.
Calendly today
Booking links, connected calendars, availability rules, reminders, and team scenarios are supplied as a service. You use its product and integration model.
The Kraton direction
Reuse and verify the underlying functions, keep your rules and state in your app, and choose how people reach it. The current demos are pieces of this service, not feature parity with Calendly.
The founding calendar order is open for a precise specification, adversarial verification, and proposals for formal proof. Its budget and bids are shown as they actually stand.