Data Flows

Cronofy holds data in line with the Cronofy Data Management policy.

This page describes in more detail how authorization is obtained, and how the data is processed and stored.

Table of contents

Authorization #

End-users connecting their calendars and adjacent services #

Cronofy provides authorization flows for end-users to grant access to their calendars and adjacent services such as video conferencing.

End-user authorization process #

Cronofy must be granted access to the underlying provider by the end-user completing an authorization process.

Calendar providerCronofyCalendar providerCronofypar[OAuth token exchange]par[Provider OAuth flow]End-userConnection initiation1User presented authorization challenge2Code for authorized challenge sent via browser3Redeem code for OAuth tokens server-to-server4OAuth tokens5Authorization complete6End-user

Similar processes are undertaken for supporting services such as video conferencing providers. Authorization and authentication models vary, but OAuth 2.0 with bearer tokens is the most common model.

Integrator authorization process #

When an API integrator is requesting access to an end-user’s schedule, there is an additional layer of authorization where the end-user grants the integrator a level of access to the data held by Cronofy about them.

Calendar providerCronofyAPI integratorCalendar providerCronofyAPI integratorpar[OAuth token exchange]par[Provider OAuth flow]par[OAuth token exchange]par[Cronofy OAuth flow]End-userConnection initiation1User presented authorization challenge2User presented authorization challenge3Code for authorized challenge sent via browser4Redeem code for OAuth tokens server-to-server5OAuth tokens6Code for authorized challenge sent via browser7Redeem code for OAuth tokens server-to-server8OAuth tokens9Authorization complete10End-user

Synchronization #

Once a connection is established to an end-user’s schedule, Cronofy continually updates a cache of their schedule in order to provide its scheduling services. This synchronization can be split broadly into two types:

  1. The end-users’ schedule changing via their calendar provider - eg. them putting events into their calendar themselves
  2. The end-users’ schedule being changed via Cronofy - eg. an integrator making an API call to create an event in their calendar

Calendar provider synchronization #

Where possibly Cronofy uses change notification mechanisms exposed by the calendar provider to minimize data transfer. When notified of a change, Cronofy ensures its corresponding cache of data is accurate.

If a change notification mechanism is not available, then polling is used to detect and apply changes.

Calendar providerCronofyCalendar providerCronofyloop[Every 5 minutes]alt[Change notifications available]par[Change detection]par[Calendar synchronization]Register for notifications1Change notification2Poll for changes3List of changes4Change detected5Fetch changes to calendar6Update cache with changes to calendar7

Cronofy is passive in this process, accepting the calendar provider’s view of the data as the truth.

Integrator action synchronization #

Integrators can initiate changes to end-users’ schedules when granted sufficient permissions.

These changes are processed by Cronofy and then applied to the end-user’s calendar as necessary.

Calendar providerCronofyAPI integratorCalendar providerCronofyAPI integratoralt[Change required]Request to update the state of a calendar event1202 Accepted response2Reconcilation of request with known state3Calls necessary to move the event into the requested state4

Whilst Cronofy is more active in this process, it is only triggered by the end-user, or an integration acting on behalf of an end-user.