July 15, 2022 - v2022.10

  • Issue #319, #1240: Fix allDay parameter in POST /setup/v1/calendar/{id}/blocks, PUT /setup/v1/calendar/blocks/{id}, POST /setup/v1/resources/{id}/block, PUT /setup/v1/resources/block/{id}, POST /setup/v1/resources/{id}/allocations, PUT /setup/v1/resources/allocations/{id}, POST /setup/v1/service/{id}/block, PUT /setup/v1/service/block/{id}, POST /setup/v1/services/{id}/allocations, and PUT /setup/v1/services/allocations/{id}
  • Issue #768: Prevent PUT /setup/v1/calendars/blocks/{id} and PUT /setup/v1/resources/block/{id} from wiping out startTime, endTime, and reason if not provided in the request body
  • Issue #901: Add deletedStatus to CalendarBlock response
  • Issue #1040: Add validation requiring reason for POST /setup/v1/resources and POST /setup/v1/services
  • Issue #1074: Fix issue where GET services in consumer and setup interface would provide the calenderId from the primary location instead of the specified location
  • Issue #1147: Add validation to POST /setup/v1/services to limit service name to 50 chars
  • Issue #1186: GET /setup/v1/services/{id}/block remove time part from response of startDate/endDate
  • Issue #1229: Add validations for startDate, endDate, startTime, endTime for POST /setup/v1/calendar/{id}/blocks, PUT /setup/v1/calendar/blocks/{id}, POST /setup/v1/resources/{id}/block, PUT /setup/v1/resources/block/{id}, POST /setup/v1/resources/{id}/allocations, PUT /setup/v1/resources/allocations/{id}, POST /setup/v1/service/{id}/block, PUT /setup/v1/service/block/{id}, POST /setup/v1/services/{id}/allocations, and PUT /setup/v1/services/allocations/{id}
  • Issue #1294: Update stored procedure when calculating available days to consider when a service allocation has been deleted
  • Issue #1302: Add AppInsights configuration to API

June 17, 2022 - v2022.9

  • Issue #1193: Add ability to cache Company and Location objects in Redis
  • Issue #1313: Validate resource exists on a the provided location in POST /consumer/v1/appointments
  • Issues #1302, #1315, #1316, #1317, #1318: Improve logging capability

May 16, 2022 - v2022.8

  • Issue #241: Update Swagger comments for PUT /setup/v1/locations/{id}/settings/scope/{settingsScope} endpoint
  • Issue #321: Fix issue where PUT /setup/v1/locations/{id}/settings/scope/{settingsScope} was incorrectly storing data when altering scopes
  • Issue #447: Add setup endpoints for ServiceGroups
  • Issue #520: Update POST /setup/v1/services to validate MaxCapacity and MaxGroupSize are both either 0 or both are greater than 0. One cannot be set without the other
  • Issue #560: Add consumer endpoints for ResourceGroups
  • Issue #561: Resolve an issue where passing an endDate=9999-12-31 and endTime=2400 in POST /setup/v1/services/allocations threw an error
  • Issue #610: Add validation to POST /setup/v1/locations to prevent names > 50 char
  • Issue #910: Add deprecation notice to locations endpoints notifying customers that we will change the settings: businessId property to settings: locationId. During the transition period both properties will be returned
  • Issue #946: Prevent an appointment with status=IN from being created when POST appointment fails a email/name validation when using completeBooking
  • Issue #954: POST /setup/v1/services/allocations prevent error from occuring when posting with endDate: 9999-12-31 and endTime: 2400
  • Issue #1007: Fix error where GET /consumer/v1/locations would throw a 500 error in certain scoping situations. We have prevented those situations from happening with issue #321, but wanted to exclude the possiblity of a 500 error being thrown
  • Issue #1010: Add validation for TimezoneName to POST/PUT /setup/v1/companies endpoints to enforce IANA names only
  • Issue #1079: Alter POST/PUT /setup/v1/locations to alter availability functionality. When setting is24hours: true, we will set fromTime: 0, toTime: 2400, and isOpen: true irrespective of the values passed in. That is to say, is24Hours: true takes precedence over other availability settings.
  • Issue #1199: Add missing IANA time validation for America/Phoenix
  • Issue #1220: Update POST/PUT /setup/v1/services to remove the validation check durationInterval >= durationMin. A new validation has been added to assure durationMin is evenly divisible into durationMax. GET /consumer/v1/availability has been updated to assure that serviceDuration is between durationMin and durationMax if durationSelect: true
  • Issue #1257: Add deprecation warning for all locations endpoints concerning the following parameters on the settings object: businessId, enabled, familyMembersEnabled, serviceLabel, resourceLabel, resourceAnyLabel, resourceSelection, liveMode, formFlow, availabilityForm, showServiceGroups, showOnSchedLogo, showBusinessLogo, disableAuthorization, hideNavBar, hideLocationNav, hideServiceGroupsNav, hideServicesNav, hideContinueBooking, returnToService, returnToAvailability, hideBreadCrumbNav. These parameters were intended for internal use in our Portal application. They will be removed from the API sometime after Aug 15.

April 22, 2022 - v2022.7

  • Issue #340: Add validation for duration when using POST /setup/v1/services to prevent 0 duration services from being posted
  • Issue #920: Fix issue where booking reminders were not being cued on the POST /consumer/v1/appointments endpoint when completeBooking was set to BK or RS
  • Issue #961: Fix issue which prevented successful creation of new Companies via the POST /setup/v1/companies endpoint
  • Issue #1111: Fix for GET /consumer/v1/locations when using the nearestTo parameter, when searched location would result in ambiguous results from Google Maps API. The endpoint will now display a warning asking the user to refine their search with more specificity.

April 7, 2022 - v2022.6

  • Issue #387: Add better validation errors when a 401 error is caused by unauthorized resource, service or location ids
  • Issue 562: Update documentation for GET /consumer/v1/settings to note that this endpoint is DEPRECATED
  • Issue #567: Update POST /setup/v1/services/{serviceId}/allocations Swagger documentation
  • Issue #598: Update POST /setup/v1/companies to add validation for TimezoneName, which is a required field
  • Issue #992, #1135: Update /consumer/v1/appointments endpoints to unify logic for multi-resource booking and single resource booking
  • Issue #949: Fix response output for POST /consumer/v1/appointments to correctly show input timezone when completeBooking: 'BK' or 'RS' is passed
  • Issue #1013: Update GET /consumer/v1/locations and GET /setup/v1/locations to allow searching by location friendlyId parameter. This will allow searching locations when customers use GUIDs as friendlyIds
  • Issue #1064: Clarify Swagger documentation for PUT /consumer/v1/appointments/{id}/reschedule
  • Issue #1088: Add PUT /setup/v1/resources/{id}/services endpoint to allow updating resource services instead of deleting and posting new ones
  • Issue #1115: Add skipTimePastUnavailability parameter to GET /consumer/v1/availability/..../unavailable to exclude Time Past (TP) blocks in data.
  • Issue #1119: Update PUT /consumer/v1/appointments/{id}/reschedule to allow both resourceId and serviceId to be altered in 1 call
  • Issue #1120: Update POST /consumer/v1/appointments and PUT /consumer/v1/appointments/{id}/reschedule to fix issue where it was incorrectly calculating the remaining group capacity and throwing an invalid validation error
  • Issue #1121: Update POST /setup/v1/resources/{id}/allocations to display startDate/endDate as Date objects, instead of DateTime objects
  • Issue #1122: Update GET /setup/v1/resources/{id}/allocations, GET /setup/v1/resources/allocations/{id}, and PUT /setup/v1/resources/allocations/{id} to display startDate/endDate as Date objects, instead of DateTime objects
  • Issue #1123: Update DELETE /setup/v1/resources/allocations/{id} to display startDate/endDate as Date objects, instead of DateTime objects
  • Issue #1125: Correct issue where UnavailableTime stored procedure was returning resource allocations in UTC time when the resource did not have a timezone set

March 23, 2022 - v2022.5

  • Issue #1095: Update GET /consumer/v1/availability and GET /consumer/v1/availability/.../unavailable to correctly adjust for DST changes when the startDate and endDate span the DST switch over time

March 6, 2022 - v2022.4

  • Issue #432: Correct issue where appointment response did not correctly display the booked timezone offset
  • Issue #587: Update content of BOOKING-408 error to include the group size requested and the group size allowed
  • Issue #609: Update GET /consumer/v1/locations/{id} to correctly display value of bookingTimerMinutes
  • Issue #913: Allow serviceAllocations to set bookingLimit to 0 in PUT /setup/v1/services/serviceAllocaitons/{id}
  • Issue #948: Update PUT /consumer/v1/appointments/{id}/reschedule to properly handle multi-resource appointment rescheduling
  • Issue #985: Default calendar availability to 24x7 if no availability data supplied to POST /setup/v1/calendars
  • Issue #1030: Modify all calls to AddException to use keyword parameters to disambiguate overloaded methods
  • Issue #1072: Update simple availability checking to properly handle existing appointments that span across midnight

Feb 10, 2022 - v2022.3

  • Issue #251: Include publicHolidayId in list of location.businessHolidays for location responses
  • Issue #286: Fix to POST /setup/v1/locations/bulk which prevents save of any locations if one location contains a validation error
  • Issue #316: Prevent location from having multiple default services. Location may still have 2 defaults if one is company scoped and the other is location scoped
  • Issue #575: Add endpoints to set/update appointment reminder schedule for a location. New endpoints GET/PUT /setup/v1/locations/{id}/appointmentreminders
  • Issue #588: Update BOOKING-138 error message to give more detail about how much capacity was requested and how much capacity currently exists
  • Issue #775: Prevent PUT ​/consumer​/v1​/appointments​/{id}​/book and PUT /consumer/v1/appointments/{id}/reserve from wiping out customer name when set in POST call. Added email validations to email addresses supplied during appointment processing.
  • Issue #764: Fix problem where PUT /consumer/v1/appointments/{id}/reschedule was removing multi-resource booking information
  • Issue #818: Add ResourceEmail to complement the existing resourceId and resourceName in the appointment response payload for consumer appointments endpoints
  • Issue #906: Fix erroneous timezone offset in appointment response payloads when using PUT /consumer/v1/appointments/{id}/book
  • Issue #918: Update POST /setup/v1/locations to default new
  • Issue #942: Update POST /setup/v1/services to prevent 500 error when options object not supplied
  • Issue #945: Prevent email validation in issue #775 if the customer has turned company.disableEmailAndSmsNotifications = true (EMAIL IS OFF)
  • Issue #952: Update PUT /consumer/v1/appointments/{id}/reschedule to properly handle customerBookingsPerDay parameter when rescheduling
  • Issue #965: Update PUT /setup/v1/resources/{id} to allow resource to correctly store notificationType
  • Issue #978: Prevent PUT /consumer/v1/appointments/{id}/book from wiping out value of groupSize parameter when finalizing a booking
  • Issue #969: Validate order of reminders when using POST/PUT /setup/v1/locations/{id}/appointmentreminders

Jan 23, 2022 - v2022.2

  • Correctly load environment-specific appsettings.json
  • Fix Issue #217: When calling POST /setup/v1/service the response did not contain either a companyId or locationId
  • Fix Issue #601: When calling POST /setup/v1/resources or POST /setup/v1/services, availability was not correctly set to the business default in some cases
  • Fix Issue #408: When calling PUT /setup/v1/company/{id} now correctly saves Webhook information (bookingWebhookUrl, customerWebhookUrl, reminderWebhookUrl, reminderWebhookUrl)
  • Fix Issue #873: When calling POST /consumer/v1/appointments, the customer name was being incorrectly stored when passing more than 2 names. Now all words after the first will be included in the lastName field
  • Fix Issue #775: Add email validations to PUT /consumer/v1/appointments/{id}/book and PUT /consumer/v1/appointments/{id}/reserve
  • Fix Issue #792: When calling POST /consumer/v1/appointments, PUT /consumer/v1/appointments/{id}/book or PUT /consumer/v1/appointments/{id}/reserve, we will now only create a customer when Location:Defaults:AutoUpdateCustomer parameter is set to true. This has the behaviour in the Portal application and now the API matches this functionality
  • Fix Issue #585: When calling POST /consumer/v1/appointments, the bookingLimit specified by a ServiceAllocation will now correctly override the information stored on Service:BookingLimit or Calendar:BookingsPerSlot values
  • Fix Issue #358: When calling POST /setup/v1/calendars/{id}/block now correctly validates startTime < endTime
  • Fix Issue #890: Where calling GET /consumer/v1/availability/.../unavailable would throw a 500 error when no resources exist on location
  • Fix Issue #882: Fix CustomerBookingsPerDay validation in ResourceAllocation functionality which would cause errors when using PUT /consumer/v1/appoinments/{id}/book or PUT /consumer/v1/appointments/{id}/reserve or PUT /consumer/v1/appointments/{id}/confirm
  • Fix Issue #882: Add validation for CustomerBookingsPerDay to POST /consumer/v1/appointments when completeBooking set to BK or RS
  • Fix Issue #790: When calling POST /setup/v1/services/{id}/allocations without a locationId, the primary location will be assumed if the service is company scoped, the location attached to the service will be assumed if the service is location scoped, or a validation error will be thrown if the locationId passed is not valid for the service

Jan 15, 2022 - v2022.1

  • Added Resource Allocation functionality to the API endpoints and to the availability functionality
  • Fix Issue #868: When calling PUT /setup/vs/resources{id} with a serviceId an HTTP 500 error was returned
  • Fix Issue #846: When calling GET /setup/v1/resources/{id}/allocations, some allocations were not returned. Fixed to return allocations within or overlapping the supplied startDate and/or endDate
  • Fix Issue #831: When calling PUT /setup/v1/locations/{id}/holidays with an asterisk (*), HTTP 500 error was returned
  • Fix Issue #777: When calling POST /consumer/v1/appointments with FIRSTNAME & LASTNAME did not save name info in the appointment
  • Fix Issue #776: When calling PUT /consumer/v1/appointments/{id}/book the Customer Record was not updating properly
  • Fix Issue #773: When serviceId was not passed into GET /consumer/v1/services/{id} or GET /setup/v1/services/{id} an incorrect error response was sent
  • Fix Issue #758: Added required and max length field validation (255 characers) for Name on Services and Resources
  • Fix Issue #750: POST /consumer/v1/resource added required and max length field validation (255 characers) for Name
  • Fix Issue #721: POST /consumer/v1/appointments updated Swagger to remove misleading statement re: multiple customerId's
  • Fix Issue #452: PUT /setup/v1/resources/allocations/{id} and PUT /setup/v1/resources/block/{id} was removing previously stored data