Trouble updating working hours via API – schedule not saving changes

[ooommmp]

Body:
Hi, I’m trying to update working hours on a schedule via the API but the changes don’t seem to persist.

Here’s what I’m doing:

curl --location --request PATCH 'https://api.cal.com/v2/schedules/860961'
--header 'Content-Type: application/json'
--header 'Authorization: Bearer <my_token>'
--data '{
"workingHours": [
{
"days": [1, 2, 4, 5],
"startTime": 480,
"endTime": 1020
}
]
}'

But when I fetch the schedule afterwards with:

curl --location 'https://api.cal.com/v2/schedules/860961'
--header 'Authorization: Bearer <my_token>'

I still see this:

"workingHours": [
{
"days": [1, 2, 3, 4, 5],
"startTime": 540,
"endTime": 1020,
"userId": 1730116
}
],
"schedule": [
{
"days": [1, 2, 3, 4, 5],
"startTime": "1970-01-01T09:00:00.000Z",
"endTime": "1970-01-01T17:00:00.000Z"
}
]

It seems to always revert to Mon–Fri, 09:00–17:00.

What I actually want is:
• Schedule 1
• Mon–Fri: 09:00–13:00 and 14:00–18:00
• Sat: 09:00–13:00
• Sun: closed
• Schedule 2
• Mon: 08:00–17:00
• Tue: 08:00–17:00
• Wed: 08:00–17:00
• Thu: 08:00–17:00
• Fri: 08:00–17:00
• Sat: closed
• Sun: closed

Am I using the API incorrectly, or do I also need to update the schedule array alongside workingHours?

Thanks in advance! 🙏

[dosubot[bot]]

Hi @ooommmp! I'm Dosu and I’m helping the cal.com team.

You need to update both the workingHours and schedule fields together in your PATCH request for changes to persist. The API expects these fields to be kept in sync; if you only update one, the other may revert to its default (Mon–Fri, 09:00–17:00) or overwrite your changes. This is how the web app handles updates internally, and the backend enforces this logic to avoid erasing or resetting schedules if only part of the data is provided. For complex schedules (multiple intervals per day, closed days), you should structure your payload to include both fields, with each interval and closed day explicitly represented in the schedule array alongside your workingHours blocks.
See the relevant code and comments for details.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[ooommmp]

When i try with

{
"status": "error",
"timestamp": "2025-09-23T15:04:21.494Z",
"path": "/v2/schedules/860961",
"error": {
"code": "BadRequestException",
"message": "Bad Request Exception",
"details": {
"errors": [
{
"target": {
"schedule": [
{}
]
},
"value": [
{}
],
"property": "schedule",
"children": [
{
"target": [
{}
],
"value": {},
"property": "0",
"children": [
{
"target": {},
"property": "start",
"children": [],
"constraints": {
"isString": "start must be a string"
}
},
{
"target": {},
"property": "end",
"children": [],
"constraints": {
"isString": "end must be a string"
}
}
]
}
]
}
]
}
}
}

I get a 400 Bad request error
{
"status": "error",
"timestamp": "2025-09-23T15:04:21.494Z",
"path": "/v2/schedules/860961",
"error": {
"code": "BadRequestException",
"message": "Bad Request Exception",
"details": {
"errors": [
{
"target": {
"schedule": [
{}
]
},
"value": [
{}
],
"property": "schedule",
"children": [
{
"target": [
{}
],
"value": {},
"property": "0",
"children": [
{
"target": {},
"property": "start",
"children": [],
"constraints": {
"isString": "start must be a string"
}
},
{
"target": {},
"property": "end",
"children": [],
"constraints": {
"isString": "end must be a string"
}
}
]
}
]
}
]
}
}
}

[ooommmp]

@dosu

[dosubot[bot]]

You’re getting the 400 Bad Request error because the schedule array in your PATCH payload is missing required fields: each object must have start and end as strings (not numbers or empty), likely in ISO 8601 format or "HH:mm" (e.g., "09:00", "13:00"). To persist changes, update both workingHours and schedule together, with each interval explicitly defined.

For your use case, your payload should look like this:

{
  "workingHours": [
    { "days": [1,2,3,4,5], "startTime": 540, "endTime": 780 },    // 09:00–13:00
    { "days": [1,2,3,4,5], "startTime": 840, "endTime": 1080 },   // 14:00–18:00
    { "days": [6], "startTime": 540, "endTime": 780 }             // Sat 09:00–13:00
  ],
  "schedule": [
    { "days": [1,2,3,4,5], "start": "09:00", "end": "13:00" },
    { "days": [1,2,3,4,5], "start": "14:00", "end": "18:00" },
    { "days": [6], "start": "09:00", "end": "13:00" }
    // Sun omitted = closed
  ]
}

For Schedule 2 (Mon–Fri 08:00–17:00, Sat/Sun closed):

{
  "workingHours": [
    { "days": [1,2,3,4,5], "startTime": 480, "endTime": 1020 }
  ],
  "schedule": [
    { "days": [1,2,3,4,5], "start": "08:00", "end": "17:00" }
    // Sat/Sun omitted = closed
  ]
}

Make sure every interval in schedule has both start and end as strings. Omit days you want closed. This matches the backend expectations and should resolve the error and persist your changes (reference).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[ooommmp]

@dosu

{
"statusCode": 500,
"message": "Internal server error"
}

it now rreturns a 500 code the api key is correct and corrrect everything is this on ccal.com side

[dosubot[bot]]

A 500 Internal Server Error here almost always means something went wrong on Cal.com's backend—typically an unhandled exception or a bug in how the schedule update is processed, especially when syncing workingHours and schedule together. If your payload is correctly formatted and your API key is valid, this isn't a client-side issue. There are no recent code changes or fixes for this endpoint that would explain the error, so it's likely a backend problem or a rare edge case in your data. If you have access to server logs, those would help pinpoint the root cause, but based on the code, the error is most likely on Cal.com's side and not something you can resolve from your end (reference).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}