The OnSched Data-Model Explained

How do you build a scheduling system for a mix of companies, locations, different employees, meeting rooms, and events? We will explain how the data architecture of OnSched supports these our multi-faceted and complex use cases in this article.

Everything we cover here is a part of the scheduling API’s basic functionality and can be configured through the setup API - a set of specific endpoints which enables you to create and modify your OnSched account. We will start from the highest level of the structure - the platform. Let’s dig into it!

Platform

The platform level was designed for you: the OnSched customer. Let’s say you are building a country-wide salon booking app. There would be individual salons as well as salon networks, those are going to be set up companies, but you need to have administrative control over each one of the businesses - your development team gets platform level access. 

It’s not necessary to use platform level if you have a super narrow use case, but it’s recommended if you are working on something like a marketplace. By default, you will have at least one company registered under your platform.

Companies

Going off the nationwide salon example in the previous point, each salon network, as a separate business entity would each be its own company. There are a number of unique settings like name, address, business hours, timezone, email, phone number, website, holiday schedule, and appointment reminders timings that can be scoped to apply at the company’s level.

Each company will have one business location by default, and you can add as many as required. Company settings will be default for all business locations but can be overwritten for each specific location.

API endpoint: /setup/v1/companies

Business Locations

Continuing in the salon example, each salon-network may have several or hundreds of brick-and-mortar locations. Each distinct physical location nested under one company would be a location. Locations can have their own configuration parameters fully independent from their parent company. In order to accept appointments, every business location will need to have at least one resource.

API endpoint: /setup/v1/locations

Resources

Every stylist, located in one (or many) locations will be a resource. A resource is or may be: individuals, places, or assets that will be booked. Resources are nested under specific business locations. To create a resource, you will need things like contact information, name, email, calendar authentication link, resource group, timezone, availability, avatar, contact info, conference, IDs of associated services, and a few custom fields you can use.

API endpoint: /setup/v1/resources

Resource Groups

Say you might have different types of staff on-site or different groups of hair-stylists across salon locations. Resource groups are as basic as they might seem, with just a resource name, group admin email, and description as parameters. This is an easy way to pull a list of all resources in a specific group. You can add resources to groups by updating groupId parameter for a specific resource. 

API endpoint: /setup/v1/resourcegroups

Services

Naturally, hair-stylists offer many different types of services, which is what the services endpoint facilitates: types of bookings that are offered by your resources. Each specific resource has a set of services assigned to it. A service could be associated with a primary business location, a specific location, or a single resource. It has the following parameters name, description, duration, book-ahead limit, padding, price, and cancelation fee.

API endpoint: /setup/v1/services

Conclusion

OnSched was designed to scale at every level. The data structure allows you to build complex platform-level scheduling flows and organize your users from the start, without building any workarounds!

How to get access to the OnSched API?

We love to guide our customers through the platform the first time they sign up. So: in order to gain free trial access to the OnSched API, book an intro call with our specialist. We promise it’s pressure-free 😉

1. Book an intro call & get your sandbox API keys.

2. Thoughtfully test the API for all of your user flows.

3. Request production server API keys when ready to go live.

If you have any questions about the OnSched API, we encourage you to book an intro call even if it’s not on your immediate roadmap - let's plan for the future!