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.

sequenceDiagram autonumber actor user as End-user participant cronofy as Cronofy participant calendar as Calendar provider user->>cronofy: Connection initiation activate user activate calendar par Provider OAuth flow cronofy->>calendar: User presented authorization challenge par OAuth token exchange calendar->>cronofy: Code for authorized challenge sent via browser cronofy->>calendar: Redeem code for OAuth tokens server-to-server calendar->>cronofy: OAuth tokens end end cronofy->>user: Authorization complete deactivate calendar deactivate 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.

sequenceDiagram autonumber actor user as End-user participant integrator as API integrator participant cronofy as Cronofy participant calendar as Calendar provider user->>integrator: Connection initiation activate user activate cronofy par Cronofy OAuth flow integrator->>cronofy: User presented authorization challenge activate calendar par Provider OAuth flow cronofy->>calendar: User presented authorization challenge par OAuth token exchange calendar->>cronofy: Code for authorized challenge sent via browser cronofy->>calendar: Redeem code for OAuth tokens server-to-server calendar->>cronofy: OAuth tokens end end par OAuth token exchange cronofy->>integrator: Code for authorized challenge sent via browser integrator->>cronofy: Redeem code for OAuth tokens server-to-server cronofy->>integrator: OAuth tokens end deactivate calendar end integrator->>user: Authorization complete deactivate cronofy deactivate 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.

sequenceDiagram autonumber participant cronofy as Cronofy participant calendar as Calendar provider par Change detection alt Change notifications available cronofy->>+calendar: Register for notifications calendar--)-cronofy: Change notification else loop Every 5 minutes cronofy->>calendar: Poll for changes calendar->>cronofy: List of changes end end end cronofy--)cronofy: Change detected par Calendar synchronization cronofy->>calendar: Fetch changes to calendar calendar->>cronofy: Update cache with changes to calendar end

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.

sequenceDiagram autonumber participant integrator as API integrator participant cronofy as Cronofy participant calendar as Calendar provider integrator->>cronofy: Request to update the state of a calendar event cronofy->>integrator: 202 Accepted response cronofy--)cronofy: Reconcilation of request with known state alt Change required cronofy->>calendar: Calls necessary to move the event into the requested state end

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.