API Reference

ShopOwner Resource

RequestShopKey EndPoint

The RequestShopKey endpoint is the first step in obtaining a ShopKey, which serves as a unique identifier for a shop within the system. This is a POST request that requires a valid RapidApiKey in the headers and a RecoveryEmail in the request body. The system verifies the API key and, upon success, generates a 6-digit temporary code, which is sent to the provided email address. This temporary code is valid for 5 minutes and is required to complete the ShopKey creation process. The endpoint returns a success response when the request is processed correctly. If required parameters are missing, a 400 Bad Request response is returned. Unauthorized API keys receive a 401 Unauthorized response. If an internal server error occurs, a 500 Internal Server Error response is sent, and an administrator is notified. This endpoint ensures that ShopKeys are only requested by authorized users and provides a secure mechanism for initiating the shop creation process.

GenerateShopKey EndPoint

The /GenerateShopKey endpoint issues a permanent ShopKey after a valid TempCode has been provided. This ShopKey will be linked to your RecoveryEmail and is required for all future API requests.

Clients must confirm agreement to the Terms and Conditions before proceeding. This is done by setting the AgreedToTerms field to true.

Once issued, the ShopKey cannot be retrieved if lost. However, a new key can be created using the same RecoveryEmail. It is your responsibility to protect this key and keep it secure. Any misuse, leakage, or unauthorized access to your key is your liability.

RequestShopKeyReplacement EndPoint

RequestShopKeyReplacement is used when you’ve lost your original ShopKey, or it got leaked. This endpoint initiates a verification process to ensure only authorized users can request replacements. A temporary code will be sent to your email, which you’ll need to confirm via the /ReplaceShopKey endpoint. This is the first step in recovering access. You must include your RecoveryEmail in the request body, and the X-RapidAPI-Key in the header for authentication. After a successful call, a response will indicate that the verification code has been sent to the provided email address.

ReplaceShopKey EndPoint

ReplaceShopKey is the second step in recovering access to your account when your original ShopKey has been lost. After successfully requesting a TempCode via the /RequestShopKeyReplacement endpoint, this endpoint is used to verify that code and generate a new ShopKey. You must include your TempCode and RecoveryEmail in the request body, and both X-RapidAPI-Key and X-Shop-Key headers from your original credentials must be present. Upon successful verification, a new ShopKey will be returned. Your old key will be deactivated, and all future API requests should use the new key. Be sure to store this new ShopKey securely, as it cannot be retrieved if lost again.

RequestNewRAKMapping EndPoint

RequestNewRAKMapping is used when you need to rotate your RapidAPI key or if you believe your current key has been leaked. This endpoint allows you to map a new RapidAPI key to your existing ShopKey and RecoveryEmail by verifying the old key. It is part of a two-step recovery process. If your old key is valid, the system will generate and send a temporary code to your recovery email. You will then use that code with the /MapNewRAK endpoint to complete the switch. This process ensures that only verified users can rotate keys or respond to a security breach. However, if your key is completely lost — meaning you no longer know what your original RapidAPI key was — this API cannot assist in recovery. For this reason, we recommend you store your RapidAPI key securely and consider regular key rotation as a security best practice.

MapNewRAK EndPoint

MapNewRAK allows you to finalize the transition from an old RapidAPI key to a new one. After requesting a new RapidAPI key mapping, the temporary code you received must be redeemed using this endpoint. Successfully mapping your key ensures that all existing ShopKey relationships remain intact with the new RapidAPI key. This operation is critical if a leak is suspected or if regular key rotation is needed for security. Without completing this mapping step, your API calls may fail. Always keep your ShopKey and RapidAPI key secret to avoid unauthorized use.

Shop Resource

AddShop EndPoint

The AddShop endpoint is used to create a new shop in the system. This is typically the first step after generating a ShopKey. It stores key information about the shop, such as its name, address, contact details, and timezone. You must supply valid authentication headers, including both x-rapidapi-key and x-shop-key, for this request to be accepted. A shop can only be added once for a given API key pairing. After successful execution, the shop is officially registered and can be linked to stylists, schedules, and catalog services.

GetShop EndPoint

The GetShop endpoint retrieves the profile of the currently authenticated shop. This includes metadata such as the shop name, contact information, location, and assigned time zone. Clients must supply a valid X-RapidAPI-Key and X-Shop-Key in the header. This endpoint is typically used after onboarding is complete and you want to display the shop details in a dashboard or profile page. The response will contain all shop information currently on file. If you wish to update this information, use the appropriate endpoint under the Shop Resource. The response will not include the ShopKey or RapidApiKey, as those are provided in the request headers and managed internally. This endpoint is useful for confirming that your credentials are working and that the shop has been successfully initialized in the system.

UpdateShop EndPoint

UpdateShop is used to update details about an existing shop. This includes information like address, contact name, phone number, and timezone. This endpoint requires both a valid X-RapidAPI-Key and X-Shop-Key in the request headers to authenticate the request. If successful, the shop’s profile is updated and a success response is returned. Any attempt to modify a non-existent or unauthorized shop will result in an error. You may choose to update only the fields you need—just be sure to provide valid formatting for any field you include.

DeleteShop EndPoint

DeleteShop allows you to permanently delete a shop from the system. This operation should be performed with extreme caution, as deleting a shop will remove all associated records and cannot be undone. The client must supply the correct RapidAPI Key and ShopKey in the request headers for authentication. This action is restricted to prevent unauthorized shop deletions. Be sure that the request is intentional, and protect your keys to avoid accidental or malicious deletions. Always ensure you have backups or necessary exports of your shop data before using this endpoint.

ShopSchedule Resource

AddShopSchedule EndPoint

AddShopSchedule allows you to define the business hours for your shop. This endpoint supports the full week, with fields for each day to define the opening and closing time. The format for times should follow the 24-hour "HH:mm" convention (e.g., "09:00", "17:30"). You can set days off by leaving the fields blank or using null. Providing accurate hours ensures clients can schedule appointments appropriately. This endpoint requires valid authentication via the X-RapidAPI-Key and X-Shop-Key headers. Be sure to include all fields, even if some days are closed. You may call this endpoint again to overwrite the current schedule. This information will be referenced when determining available appointment slots for stylists.

GetShopSchedule EndPoint

GetShopSchedule is a read-only endpoint that returns the current business hours for the authenticated shop. This includes open and close times for each day of the week, in 24-hour "HH:mm" format. This data is crucial for applications that calculate appointment availability or want to display a public-facing schedule to customers. If a shop is closed on a particular day, the corresponding open and close fields may return null or an empty string. You must include both the X-RapidAPI-Key and X-Shop-Key headers to authenticate the request. The response does not include timezone details—only the raw schedule data. Use the GetShop endpoint if you also need timezone information.

UpdateShopSchedule EndPoint

UpdateShopSchedule allows an authenticated shop to update its weekly hours of operation. Each day of the week accepts an Open and Close time in 24-hour format ("HH:mm"). If the shop is closed on a given day, you can either omit that field or pass null. Times are stored in the shop's local timezone (as specified in the Shop record), and they must follow valid time formatting. For example, "09:00" represents 9:00 AM and "17:30" represents 5:30 PM. You must supply the X-RapidAPI-Key and X-Shop-Key in the headers. This endpoint replaces all 7 days at once, so be sure to send the full week's data in a single call.

DeleteShopSchedule EndPoint

DeleteShopSchedule removes the weekly hours of operation for a specific shop. This endpoint is useful for cases where a shop needs to temporarily close or reset their operating schedule entirely. Once deleted, the shop will have no active hours defined, and clients will not be able to book appointments until a new schedule is added using the AddShopSchedule or UpdateShopSchedule endpoint. This action is irreversible, so make sure to back up or confirm the deletion with your system if necessary. Like all endpoints, this call requires the correct X-RapidAPI-Key and X-Shop-Key headers to validate the request.

BlockShopDay EndPoint

BlockShopDay is used to block off an entire day on the shop’s schedule. This means no appointments will be accepted or processed for the specified date, regardless of the normal working hours. It's commonly used for holidays, maintenance days, or other one-off closures. Blocking a day takes precedence over the regular weekly schedule. Use this endpoint to ensure the system accurately reflects the shop's availability and prevents clients from scheduling during unavailable dates. Make sure to pass a valid DateToBlock in the body, and authenticate using the correct X-RapidAPI-Key and X-Shop-Key headers.

UnblockShopDay EndPoint

UnblockShopDay is used to remove a previously blocked day from the shop’s schedule. Once a date is unblocked, the system will resume using the shop’s regular schedule to determine appointment availability for that date. This is useful if a shop reopens on a day that was mistakenly or prematurely blocked (e.g., reopening after initially planning to close for a holiday). The request requires authentication headers and a valid date string in MM/DD/YYYY format. Be sure to only call this on dates that were previously blocked using the BlockShopDay endpoint.

GetBlockedShopDaysByDateRange EndPoint

GetBlockedShopDaysByDateRange allows you to retrieve all blocked shop days within a specified date range. This is helpful when building admin dashboards or calendar views that need to reflect blackout periods where appointments cannot be scheduled. The response will contain a list of dates that were previously blocked using the BlockShopDay endpoint. You must specify both a start and end date, and the range must not exceed 90 days. All requests must be authenticated using your valid X-RapidAPI-Key and X-Shop-Key headers.

Stylist Resource

AddStylist EndPoint

AddStylist allows shop owners to register a new stylist under their shop. Each stylist is identified by a unique screen name, which serves as their public-facing handle in the system. Adding a stylist enables them to be assigned appointments and associated with available time slots in the catalog. A stylist must be marked as active to appear in scheduling tools. This endpoint requires valid API keys passed in the headers and accepts basic information about the stylist in the body.

GetStylist EndPoint

GetStylist retrieves a list of stylists associated with the authenticated shop. This endpoint is useful for displaying active team members, assigning appointments, or managing stylist availability. Only stylists tied to the shop making the request will be returned. Each stylist includes their screen name and active status, which can be used to determine visibility and scheduling behavior. The request must be authenticated using your valid RapidAPI and ShopKey headers.

UpdateStylist EndPoint

UpdateStylist allows a shop owner to update an existing stylist's details, such as their screen name or active status. This is useful when stylists change their display name or temporarily leave the shop. The stylist must already exist in the database and must be associated with the authenticated shop. This endpoint is secured with both the RapidAPI Key and the Shop Key to prevent unauthorized updates. Be sure to provide all required fields in the request body for a successful update.

DeleteStylist EndPoint

DeleteStylist allows a shop owner to remove a stylist from their shop's system. This is typically used when a stylist permanently leaves the business and should no longer appear in scheduling interfaces or be assigned to new appointments. The stylist must be associated with the authenticated shop, and the request must include valid API credentials. This operation is permanent and cannot be undone, so proceed with caution. If you simply want to deactivate a stylist temporarily, consider using the UpdateStylist endpoint with IsActive = false instead.

GetAllStylistsByShop EndPoint

GetAllStylistsByShop retrieves a list of all stylists associated with the authenticated shop. This includes both active and inactive stylists, unless filtered otherwise. Each stylist entry contains their unique ID, screen name, active status, and contact details. This endpoint is helpful for admin dashboards, staff directories, or any feature that requires displaying or managing shop personnel. Make sure you pass valid API credentials in the headers to authorize access. The response is returned as a JSON array of stylist objects.

GetAvailabilityOutlookByDay EndPoint

GetAvailabilityOutlookByDay provides a detailed availability map for a given date. It returns a stylist's availability status for each timeslot throughout the day. It will check to see if the timeslot is available, and if the timeslot is eligible to be awarded a start time. This is useful for building client-facing booking pages or internal scheduling tools. See the Availability section of the Appointment Lifecycle page to get a better understanding about how availability works.

BlockTime EndPoint

The BlockTime endpoint allows the client to proactively block out specific 30-minute timeslots in their schedule. This can be used to indicate personal breaks, lunch, or unexpected availability changes. It accepts a list of time blocks, but only for one stylist per request. All timeslots must occur on the same day. If multiple days are desired, that will mean multiple requests. The array in the request body cannot have more than 48 individual items. If a conflict is found such as a previously scheduled appointment or overlapping block, the system will reject that individual block - while rewarding the others. The client would need to resolve those conflicts (maybe canceling appointments) and retry those failed blocks if they desire to. In the response, you will see an Id for each block. Store it in a safe place in case you need to unblock.

UnblockTime EndPoint

The UnblockTime endpoint allows a stylist to unblock a timeslot that was previously blocked. You can use the Id saved from when your original block request, or you can use the GetUnblockedTimeslotsByDate endpoint to search for blocked timeslots.

GetBlockedTimeslotsByDate EndPoint

The GetBlockedTimeslotsByDate endpoint allows clients to retrieve a list of currently active blocked timeslots for a specific stylist within a date range. This can be used to audit schedule conflicts, see recent manual block entries, or build a visual calendar of availability by excluding blocked times.

Catalog Resource

AddCatalogItem EndPoint

AddCatalogItem allows a shop to create a new service item in their catalog. This catalog is typically used to display available services to clients when they are booking appointments. Each item in the catalog has a name, price, duration in minutes, and a description. Adding a catalog item is required before a service can be attached to an appointment. You can include services such as “Men’s Haircut”, “Beard Trim”, “Shampoo and Style”, etc. The duration should reflect the actual time a stylist would need to complete the service. Authentication is required using both RapidAPI and Shop keys.

GetCatalogItem EndPoint

GetCatalogItem retrieves the details of a specific service item that exists in a shop's catalog. This endpoint is useful when you need to fetch information such as the name, price, duration, and description of a service based on its unique identifier. This can be used for display purposes, editing, or validation before scheduling an appointment. To use this endpoint, you must include the correct authentication headers and provide the CatalogItemID in the request body. If the item exists and belongs to the authenticated shop, the details will be returned. This is a read-only endpoint and does not modify any data.

UpdateCatalogItem EndPoint

UpdateCatalogItem allows a shop to make changes to an existing service offering in its catalog. This endpoint is typically used when you want to rename a service, change the price, adjust the duration, or update the service description. To execute this request, the client must pass valid authentication headers and provide the updated details along with the CatalogItemID. Only items that belong to the requesting shop can be updated. If the item exists and validation passes, the update is applied and confirmed. This is a secured write operation and should be used carefully to avoid accidental overwrites.

DeleteCatalogItem EndPoint

DeleteCatalogItem is used to permanently remove a catalog item from a shop’s list of available services. This is typically done when a service is no longer offered or was added by mistake. This operation requires authentication via both the RapidAPI key and the ShopKey, and the catalog item must belong to the authenticated shop. Once deleted, the service is no longer visible to clients and cannot be used in new appointment bookings. Be aware that deletion is irreversible—use this endpoint only when you are sure that the catalog item is no longer needed.

GetAllCatalogItems EndPoint

GetAllCatalogItems retrieves the full list of services offered by a particular shop. Each catalog item represents a service (e.g., haircut, beard trim, consultation) and includes details such as the description, duration, and price. This endpoint requires both the RapidAPI key and ShopKey for authentication. It is commonly used by client-facing applications to populate service selection menus, or by admin tools to display current offerings. This endpoint is read-only and does not alter the catalog.

Appointment Resource

CreateOrderSesssion EndPoint

The CreateOrderSession endpoint is used to create a new order session. This session serves as a way to put many appointments in a group, like ordering for a group. Clients typically call this first to obtain an OrderNumber (with 30 minute expiration), which is then reused in subsequent appointment creation requests within one session (one sitting). Now, if you are just adding one appointment, and one only, you can skip this, and the system will automatically assign an Order Number just for that appointment (see Quick Start). If you require more than one appointment (example: parent with children), then it is recommended you use the same OrderNumber, but this is optional.

AddAppointment EndPoint

AddAppointment creates a new appointment in the system. The request must include details about the shop, stylist, time, description, and the desired time slot. This endpoint supports integrations between frontend schedulers and the API, enabling clients to book appointments programmatically. It ensures that time slot conflicts are avoided and will return errors if any slots are already taken or if required fields are missing. Once the appointment is created, it will appear in the system under the associated OrderSession. The client may optionally provide a ClientSideNotificationLink for webhook updates.

GetAppointment EndPoint

GetAppointment retrieves detailed information for a single appointment based on its unique AppointmentNumber. This endpoint is typically used after an appointment has been scheduled, allowing clients to fetch full appointment metadata, including assigned stylist, time slots, status, and cancellation info. The request must include valid headers to identify the requesting shop and client. This endpoint is read-only and will not affect the status of the appointment. It is useful for rendering confirmations, displaying existing appointment records, or for administrative review.

GetAllAppointmentsByOrderNumber EndPoint

GetAllAppointmentsByOrderNumber retrieves all appointments associated with a single ReceiptNumber. This is useful for clients that scheduled multiple appointments in a single booking session, such as a group or a parent booking for multiple children. Each appointment under the same receipt will be returned in a single call. This endpoint is read-only and requires authentication via both the X-RapidAPI-Key and X-Shop-Key headers. It is often used to confirm a batch booking or to reload a client’s session in a scheduling interface.

GetAllAppointmentsByDate EndPoint

GetAllAppointmentsByDate retrieves all appointments that fall within a date range. This is useful for clients that want to know what appointments are upcomming for a given day, or what appointments were completed last week. This endpoint is read-only and requires authentication via both the X-RapidAPI-Key and X-Shop-Key headers.

GetAllAppointmentsByStylist EndPoint

GetAllAppointmentsByStylist retrieves all appointments associated with a stylist. This is useful for clients that want to know the productivity or upcoming schedule of a stylist. This endpoint is read-only and requires authentication via both the X-RapidAPI-Key and X-Shop-Key headers.

SubmitOrderSession EndPoint

The SubmitOrderSession endpoint finalizes an order session by attaching the client’s contact information to a specific OrderNumber. This marks the end of the session and updates all related appointments to a status of Requested. Once submitted, no additional appointments can be added to the session. This endpoint must be called after creating the session using CreateOrderSession and adding one or more appointments with AddAppointment. After submission, the client can use ConfirmAppointment to confirm individual appointments. Confirmation is not required, but webhook reminders will not work unless the appointment is confirmed. The client can cancel an appointment using CancelAppointment at any time unless the appointment already finished.

ConfirmAppointment EndPoint

The ConfirmAppointment endpoint allows the client to confirm an appointment once the stylist has accepted it. This step finalizes the booking and updates the appointment status accordingly in the system. Both the RapidAPI key and the ShopKey must be valid for the confirmation to succeed. The client must provide the appointment number they wish to confirm.

CancelAppointment EndPoint

The CancelAppointment endpoint allows the client to cancel an appointment at anytime - unless the appointment is already finished. The system does not 'delete' appointments. You can still access details using other endpoints like GetAppointment. Both the RapidAPI key and the ShopKey must be valid for the confirmation to succeed. The client must provide the appointment number they wish to confirm.