How can I implement Round Robin scheduling?

Read as Markdown

There are two approaches depending on whether you are building a custom scheduling UI using the Availability API directly, or using Real-Time Scheduling to generate a booking URL.

Approach 1: Availability API with participant ordering #

When making an Availability Query, participants are preferred in the order they appear in the request. Members listed earlier are preferred over those listed later - Cronofy will use the first available participant who has an open slot.

This gives you direct control over who is most likely to be selected. There are two common ways to use this for round robin:

Shuffle for even distribution - Randomise the participant order on each query. Over time this produces an approximately even spread across the team without any additional tracking.

Order by least booked - Track how many events each person has been assigned, then sort participants from fewest to most bookings before each query. This more actively rebalances load and lets you control the window you’re measuring against. To achieve this, the amount of available time each of the event receivers has needs to be measured and recorded. This is so that those with the largest amount of available free time, represented in open blocks on the scheduler, can be assigned events first.

In this example, Alice has 5 interviews booked this week and Bob has 2, so Bob is placed first to make him more likely to be selected. Each member is identified by their sub value, and you can optionally scope the query to specific calendars using calendar_ids:

Example Request #

POST /v1/availability HTTP/1.1
Host: {data_center_url}
Authorization: Bearer {API_KEY}
Content-Type: application/json; charset=utf-8

{
  "participants": [
    {
      "members": [
        {
          "sub": "acc_5ba21743f408617d1269ea1e",
          "calendar_ids": ["cal_n23kjnwrw2_jsdfjksn234"]
        },
        {
          "sub": "acc_64b17d868090ea21640c914c"
        }
      ],
      "required": 1
    }
  ]
}

The required field controls how many members must be available for a slot to be returned. The example above uses "required": 1, so a slot is returned when at least one member of the group is available - combined with the member ordering, this gives round robin behaviour: the first-listed participant is preferred, falling back to the next when they are busy. Setting it to "all" would instead require every member to be free simultaneously, which is panel scheduling rather than round robin.

The typical flow after an Availability Query is to create an event against the selected participant’s calendar using the Upsert Event endpoint.

Approach 2: Real-Time Scheduling with event_creation: “single” #

If you are using Real-Time Scheduling to generate a booking URL, you can achieve round robin behaviour using the event_creation parameter set to "single".

When event_creation is set to "single" and multiple target_calendars are specified, Cronofy creates the event in one calendar only - using the order of participants in the Availability Query to determine who is preferred. You can use target_calendars.attendee to configure how the non-selected participants are added to the event as attendees. Please see the fully worked example in the Real-Time Scheduling API reference.

As with the Availability API approach, the participant order controls distribution:

  • Shuffle the order on each scheduling link for an approximately even spread.
  • Sort by least booked first for more active load balancing.

If you’d like further clarification, please email support@cronofy.com and we’ll be happy to help!