# Update Special Business Hours This endpoint updates a store's special business hours, enforcing non-overlapping date ranges and supporting full-day closures or complete configuration clearance. 1. Multiple SpecialBusinessHourDTO entries must have non-overlapping date ranges (startDate to endDate) to prevent scheduling conflicts and ensure operational clarity. 2. To indicate 24-hour closure during a period, submit one SpecialBusinessHourDTO with startTime=0 and endTime=0. 3. To completely clear all special business hours configurations, set the specialBusinessHour field to either null or an empty array [] in your request payload. Endpoint: POST /scm/shop/special/business/hour/effective/update Version: v.1.0.0 ## Request fields (application/json): - `shopId` (integer, required) Store ID Example: 466663 - `specialBusinessHour` (array, required) Special business hours list - `specialBusinessHour.startDate` (integer, required) Start date timestamp (milliseconds) for of the day timestamp example: 1690214400000 (2023-07-24 00:00:00 UTC) Example: 1690214400000 - `specialBusinessHour.endDate` (integer, required) End date timestamp (milliseconds) for of the day timestamp example: 1690646399999 (2023-07-28 23:59:59.999 UTC) Example: 1690646399999 - `specialBusinessHour.businessHour` (array, required) Operating hours during [startDate, endDate] period Full-day closure: Single DTO with startTime=0 and endTime=0 - `specialBusinessHour.businessHour.startTime` (integer, required) Start time of business period in seconds: - Range: 0 (midnight) to 86400 (next midnight) - For full-day closure: Set to 0 along with endTime=0 - Time periods must not overlap within the same day Example: 27000 - `specialBusinessHour.businessHour.endTime` (integer, required) End time of business period in seconds: - Must be >= startTime except for cross-day periods - For full-day closure: Set to 0 along with startTime=0 Example: 28000 ## Response 200 fields (application/json): - `code` (integer, required) A numeric status identifier indicating the result of the interface call, used to determine whether the operation executed successfully. - `message` (string, required) Text description corresponding to the status code, explaining the operation result or error cause to users. Example: "Success"