Appointment API

Besides calls to read or update appointments, this API provides methods to retrieve a subset of recent changes, or to retrieve availability information of a schedule. Note that not all schedule types support all methods. These API endpoints are available to retrieve and manipulate appointment information:

1. Recent Changes – /api/changes – List changes since a specified date
2. List Appointments – /api/range – List appointments in a time range
3. Agenda – /api/agenda – Retrieve the appointments of a single user
4. Availability – /api/free – Retrieve a list of free spaces
5. Appointments – /api/bookings – Create, read, update and delete appointments
6. Slots – /api/slots – Create, read, update and delete slots (capacity type only)

The API accepts data as URL parameters, as JSON or as XML, and can return data as either JSON or XML. When you send JSON or XML in the request body, wrap the fields in a top-level object named after the thing you are sending: booking for the Appointments API and slot for the Slots API.

Authentication

You typically include your API key with each request, as a header or a parameter, but you can also authenticate via a checksum. Please refer to the Authentication page for details.

The Recent Changes API

All input values need to be URL encoded. The system will respond with a list of all appointments that have seen a change recently, or since the time specified by the from parameter.

{
  "bookings": [
    {
      "id": "123456",
      ...
    }
  ]
}

<bookings>
   <booking>
      ...
   </booking>
   <booking>
      ...
   </booking>
</bookings>

If you include the parameter slot=true on a request for a capacity-type schedule, the document will be formatted as a tree of slots containing the relevant bookings:

{
  "slots": [
    {
      ...
      "bookings": [
        {
          "id": "123456",
          ...
        }
      ]
    }
  ]
}

<slots>
   <slot>
      ...
      <bookings>
         <booking>
            ...
         </booking>
         <booking>
            ...
         </booking>
      </bookings>
   </slot>
   <slot>
      ...
   </slot>
</slots>

All times are returned in the format YYYY-MM-DD HH:MM:SS, irrespective of the account settings. Start and finish time use the time zone for the calendar, the created_on and updated_on fields are in UTC.

Alternatives to using the Recent Changes API

If you want to keep a back-end system updated with changes made on a SuperSaaS schedule, there are several alternative options:

• Instead of frequently polling our server to see if anything changed it is preferable to configure a webhook. The webhook can actually be configured to supply every change as a payload so it may make polling entirely unnecessary.
• You can publish your schedule to a Google Calendar and use Google’s extensive API to query it.
• You can use the webcal interface. This is an RFC 2445 compliant interface for which several client libraries exist. However, the iCalendar format allows only limited details about an appointment to be transmitted.
• You can send an email (or SMS) notification to yourself and extract the relevant values from those messages. This requires setting up an automatic email reader.

The List Appointments API

All input values need to be URL encoded. For Resource and Service schedules, the system will respond with a list of appointments in the requested range.

{
  "bookings": [
    {
      "id": "123456",
      ...
    }
  ]
}

<bookings>
   <booking>
      ...
   </booking>
   <booking>
      ...
   </booking>
</bookings>

If you specify a “capacity”-type schedule, the system will respond with a list of slots in the requested range.

{
  "slots": [
    {
      "id": "123456",
      ...
    }
  ]
}

<slots>
   <slot>
      ...
   </slot>
   <slot>
      ...
   </slot>
</slots>

If you include the parameter slot=true in the request for a capacity-type schedule, the bookings inside the slots will be included:

{
  "slots": [
    {
      ...
      "bookings": [
        {
          "id": "123456",
          ...
        }
      ]
    }
  ]
}

<slots>
   <slot>
      ...
      <bookings>
         <booking>
            ...
         </booking>
         <booking>
            ...
         </booking>
      </bookings>
   </slot>
   <slot>
      ...
   </slot>
</slots>

All times returned by the API are in the ISO format YYYY-MM-DD HH:MM:SS, irrespective of the account settings. Start and finish time use the time zone for the calendar, the created_on and updated_on fields are in UTC.

The Agenda API

The Agenda API allows you to retrieve the appointments for a single user. You can optionally do authentication with a one-way hash to allow retrieval through a client-side AJAX request from a user’s browser. Output fields are identical to those listed for the Recent Changes API.

If you omit the schedule_id parameter, appointments for all schedules in the account will be listed. In that case, however, you need to add an account parameter to specify the name of the account for which you want to retrieve the appointments.

For example, the following call would show all appointments for a user for each schedule in the account:

All input values need to be URL encoded. The system will reply with a document that lists all appointments occurring after the from time. The output fields are identical to those for the Recent Changes API.

{
  "bookings": [
    {
      "id": "123456",
      ...
    },
    {
      "id": "789123",
      ...
    }
  ]
}

<bookings>
   <booking>
      ...
   </booking>
   <booking>
      ...
   </booking>
</bookings>

The Availability API

The Availability API allows you to retrieve a list of free spaces in a specific schedule. Note that this API does not support “Service”-type schedules (because that schedule type calculates the available space in the browser).

If you call this endpoint repeatedly, we recommend including an If-Modified-Since header. This will allow the server to quickly respond with a 304 Not Modified response if nothing changed since your last request. Note that the number of free spots can also change due to the time passing because a schedule does not allow appointments to be made in the past. The 304 Not Modified response does not take this into account.

The system will reply with a document that lists all free spaces occurring after the from time.

{
  "slots": [
    {
      "start": "2026-01-18T13:00:00",
      "finish": "2026-01-18T15:00:00",
      ...
    },
    {
      "start": "2026-01-18T15:00:00",
      "finish": "2026-01-18T18:00:00",
      ...
    }
  ]
}

<slots>
   <slot start="2026-01-18 13:00:00" finish="2026-01-18 15:00:00">
      ...
   </slot>
   <slot start="2026-01-18 15:00:00" finish="2026-01-18 18:00:00">
      ...
   </slot>
</slots>

All times are returned in the time zone for the account, and in the format YYYY-MM-DD HH:MM:SS, so irrespective of the time format in the account settings.

The Appointments API

The Appointments API allows you to create, read, update and delete appointments from a schedule. Note that it doesn’t support creating appointments in a service-type schedule. In a capacity-type schedule this API creates appointments inside an existing slot; to create the slots themselves, use the Slots API described below.

Create a new appointment

To create a new appointment, you need to send an HTTP POST request to /api/bookings.json (or .xml). The request should either contain a JSON or an XML document describing the new user, or have the fields as URI encoded parameters. See the table below for an explanation of the fields.

<?xml version="1.0"?>
<booking>
   <start>...</start>
   <finish>...</finish>
   <full-name>Full Name</full-name>
</booking>

{
  "booking": {
    "start": "…",
    "finish": "…",
    "full_name": "Full Name"
  }
}

If the booking was created correctly, the response will be a header with status code 201 Created. The Location field of the response header will contain the URL that you can use to update the appointment later, e.g.: Location: https://www.supersaas.com/api/bookings/1234.json.xml. If you want to update the booking via the API later, then you need to extract the ID of the created object (1234) from this URL.

The response will be 404 Not Found if the schedule doesn’t exist and 403 Not authorized if the api_key or checksum is incorrect. If the object did not pass validation, for example due to an invalid email address, then status 422 Unprocessable Entity will be returned, with the body of the response containing the error message.

The fields that you can supply are determined on the Configure > Process tab. The settings there also determine which values are optional and which are required. Note that in XML messages, the underscores are replaced with dashes.

Illustrative Usage: Resource Schedule

To create an appointment in the resource schedule with ID <schedule_id>, you would send the following HTTP POST request:

Appointments can more easily be created by sending a JSON encoded body in the request. The example below has the authentication and schedule ID in the URL, and the appointment information in the JSON body.

{
  "booking": {
    "start": "YYYY-MM-DD HH:MM:SS",
    "finish": "YYYY-MM-DD HH:MM:SS",
    "full_name": "Test"
  }
}

Illustrative Usage: Capacity Schedule

To create an appointment in the capacity schedule with ID <schedule_id>, you would send the following HTTP POST request:

Or with a JSON encoded body in the request:

{
  "slot_id": "slot_id",
  "full_name": "Test"
}

Read a single appointment

If the booking exists and the authorization is correct, then the response will be 200 OK with the response body containing a JSONan XML document describing the appointment.

<booking>
   ...
</booking>

{
  "id": "123456",
  ...
}

If a booking contains a custom form then adding form=true will add the attached form to the output. The format is identical to that produced by the Form API. When reading data, the retrieved document will contain the following fields in addition to the ones listed above:

Read multiple appointments

There are three specialized APIs available to retrieve multiple appointments depending on whether you want those filtered by user, by date, or by recent changes. See the beginning of this section for details. In addition to those, you can retrieve all appointments for a calendar with:

You can pass the limit=X parameter to limit the number of returned results to X. As a special case, on a resource or service type schedule you can pass a start and/or finish parameter to limit results to that time window. This allows you to retrieve the next upcoming appointment with a request like /api/bookings.json?schedule_id=123&start=2026-10-10&limit=1.

Show forms

When a form is attached to an appointment, you can show the form’s data by adding the form=true parameter to the URL. The output will be the same as that of the Form API.

Update an appointment

To update an appointment, send an HTTP PUT request to /api/bookings.json, and specify the ID of the appointment in question. Similar to creating an appointment, you can either provide a JSONan XML document or use URI encoded parameters.

The system looks for the record with the given ID and updates it. The result will be an empty response with a 200 OK status. However, if the ID is not found, for example because the appointment has already been deleted, a 404 Not Found status code is returned. Furthermore, if the object contains invalid fields the response will be a 422 Unprocessable Entity with a JSONan XML error document.

Delete an appointment

Deleting an appointment can be done by sending an HTTP DELETE request to /api/bookings.json, specifying the ID of the appointment in question.

The system will look for the ID in the database and return 200 OK if the record was deleted successfully or 404 Not found if it (no longer) exists.

The Slots API

The Slots API allows you to create, read, update and delete the slots of a capacity-type schedule. Slots are the containers that appointments are booked into, so this API is only available for that schedule type.

Create a new slot

To create a new slot, you need to send an HTTP POST request to /api/slots.json (or .xml). The request should either contain a JSON or an XML document describing the new slot, or have the fields as URI encoded parameters. See the table below for an explanation of the fields.

<?xml version="1.0"?>
<slot>
   <start>...</start>
   <finish>...</finish>
   <title>Yoga class</title>
   <capacity>12</capacity>
</slot>

{
  "slot": {
    "start": "…",
    "finish": "…",
    "title": "Yoga class",
    "capacity": 12
  }
}

If the slot was created correctly, the response will be a header with status code 201 Created. The Location field of the response header will contain the URL that you can use to update the slot later, e.g.: Location: https://www.supersaas.com/api/slots/1234.json.xml. The ID in that URL (1234) is also the slot_id you pass to the Appointments API to book somebody into the new slot.

The response will be 404 Not Found if the schedule doesn’t exist and 403 Not authorized if the api_key or checksum is incorrect. If the object did not pass validation, for example because the finish time lies before the start time, then status 422 Unprocessable Entity will be returned, with the body of the response containing the error message.

Only start and finish are required. Every other field you leave out takes the default configured for the schedule, so the shortest possible request creates a slot with the schedule’s default capacity, price and color. Note that in XML messages, the underscores are replaced with dashes.

Illustrative Usage

To create a slot in a capacity schedule, you would send the following HTTP POST request:

Or with a JSON encoded body in the request:

{
  "slot": {
    "start": "YYYY-MM-DD HH:MM:SS",
    "finish": "YYYY-MM-DD HH:MM:SS",
    "title": "Yoga class"
  }
}

Read a single slot

If the slot exists and the authorization is correct, then the response will be 200 OK with the response body containing a JSONan XML document describing the slot.

<slot>
   ...
</slot>

{
  "id": "123456",
  ...
}

Read multiple slots

Leave the ID out to retrieve the slots of a whole schedule, in order of start time:

You can pass a start and/or finish parameter to limit the results to slots starting in that time window, and limit=X to return at most X slots. The default limit is 100 and the maximum is 2500. Pass an offset parameter to page through a larger result set. So the next slot to start after a given moment can be retrieved with a request like /api/slots.json?schedule_id=123&start=2026-10-10&limit=1.

<slots>
   <slot>
      ...
   </slot>
   <slot>
      ...
   </slot>
</slots>

[
  {
    "id": "123456",
    ...
  },
  {
    "id": "123457",
    ...
  }
]

The List Appointments API returns the same slots with their bookings included, which is usually the more convenient call if that is what you need.

Update a slot

To update a slot, send an HTTP PUT request to /api/slots.json, and specify the ID of the slot in question. Similar to creating a slot, you can either provide a JSONan XML document or use URI encoded parameters. Only the fields you send are changed, the rest of the slot is left alone.

The system looks for the record with the given ID and updates it. The result will be an empty response with a 200 OK status. However, if the ID is not found, for example because the slot has already been deleted, a 404 Not Found status code is returned. Furthermore, if the object contains invalid fields the response will be a 422 Unprocessable Entity with a JSONan XML error document.

A slot that repeats was created as a series in the user interface, but the API always treats it as a single slot: updating one occurrence leaves the rest of the series untouched, and the API cannot create a new series.

Delete a slot

Deleting a slot can be done by sending an HTTP DELETE request to /api/slots.json, specifying the ID of the slot in question.

The system will look for the ID in the database and return 200 OK if the record was deleted successfully or 404 Not found if it (no longer) exists.