Rooms, people and bookings over plain HTTP. Add scheduling to your own application with a handful of calls and a library for the language you already write.
Currently version 2.4.1
chronoskin keeps the calendar and its rules. Your application asks what is free, books it, and hears about every change.
Create, move and cancel a booking with one request each. Clashes are refused with a reason your code can read.
View details »Ask for free slots by room, person or both. Opening hours, breaks and time zones are worked out on our side.
View details »Name an address and we post to it whenever a booking is made, moved or cancelled, with retries for a day.
View details »$ curl api.chronoskin.example/v2/rooms/14/free \
-u YOUR_KEY: \
-d day=2013-09-16
{
"room": 14,
"free": ["09:00", "09:30", "11:00", "14:30"]
}
Each one wraps the same calls and is released together with the API.
From nothing to a confirmed booking in about ten minutes.
Every call is an HTTPS request that answers in JSON.
You need an API key, which you send as the user name of each request. Keys come in two kinds: a test key that books nothing real, and a live key.
Ask a room for its free slots on a day. Times come back in the time zone of the room, in steps set by slot_minutes.
# free slots in room 14 on 16 September
$ curl api.chronoskin.example/v2/rooms/14/free \
-u YOUR_KEY: \
-d day=2013-09-16
Test keys are safe. A booking made with a test key is kept for an hour and never reaches a calendar.
Do not ship a live key in a web page. Anyone who reads the page source can book with it. Call the API from your server.
Post the slot back with the name of whoever it is for. The answer carries the booking and its address.
409 with the nearest free time422 with the opening hours429; wait and send it againBookings can repeat, belong to several people and tell your server when they change. The reference has every field.
Every address, what it takes and what it answers.
| Method | Address | What it does | Status | Limit |
|---|---|---|---|---|
| GET | /bookings | Lists bookings, newest first | Stable | 120 |
| POST | /bookings | Books a free slot | Stable | 60 |
| PUT | /bookings/:id | Moves or renames a booking | Stable | 60 |
| POST | /bookings/:id/repeat | Repeats a booking on a pattern | Beta | 30 |
| DELETE | /bookings/:id | Cancels a booking | Stable | 60 |
| GET | /reservations | The version 1 name for the list | Going away | 10 |
Books a free slot in one room. Send room, start and name; the length defaults to one slot.
{
"id": 90211,
"room": 14,
"start": "2013-09-16T09:30:00+02:00",
"name": "Design review"
}
Somebody else booked it first. The answer carries the nearest free time, so you can offer it straight away.
The start lies outside the opening hours of the room. The answer lists them.
Wait for the number of seconds in the Retry-After header and send the call again.
See also: Your first booking Errors Rate limits Libraries Overview
Official clients, released together with the API.
For Ruby 1.9 and later. No dependencies beyond the standard library.
$ gem install chronoskinDownload the gem
For Python 2.6 and 2.7. A build for Python 3 is in beta.
$ pip install chronoskinDownload the package
For PHP 5.3 and later. One release behind while 2.4.1 is tested.
$ composer require chronoskin/clientDownload the archive
A booking can repeat daily, weekly or on named weekdays. In beta, behind one new address.
A failed delivery is tried again for a day, at growing intervals, and listed in the dashboard.
Free slots for a whole week now come back in one call and in a third of the time.
A booking can need a person, a room or both, and availability takes all of them into account.
JavaScript, Java and Go clients are kept by their own maintainers and follow a release or two behind.
See all sixOne key for each application that calls the API.
61,400 of 100,000 on the free planresets on 1 October
Applications that use these keys stop working at once. This cannot be undone.