[{"data":1,"prerenderedAt":13},["ShallowReactive",2],{"docs-infra\u002Fwork-schedules":3,"docs-tabs-infra\u002Fwork-schedules":6},{"content":4,"lastmod":5},"# Work schedule library\n\nWork schedules for servers in the schedule run mode: the server runs during the schedule windows and sleeps outside them. The library is shared across the Bitrix24 account — one schedule can be assigned to many servers, and editing its windows immediately changes when every assigned machine runs.\n\n**Preset and custom schedules.** The platform provides the presets: `weekdays-9-18` — weekdays from 9 to 18, `weekdays-9-19` — weekdays from 9 to 19, `weekdays-9-20` — weekdays from 9 to 20, `weekdays-8-19` — weekdays from 8 to 19, `weekdays-8-20` — weekdays from 8 to 20, `daily-9-21` — every day from 9 to 21. They cannot be edited or deleted: for a different weekly pattern, create a custom schedule. The set of presets keeps growing, so a key missing from this list means a preset newer than this page, not an error. A Bitrix24 account can keep up to 50 custom schedules.\n\n**Week windows.** A window is an object `{ isoDay, start, end }` in the schedule's local time: `isoDay` from 1 (Monday) to 7, `start` and `end` as `HH:MM` in 30-minute increments, with `24:00` for the end of the day. A window lasts at least an hour and never crosses midnight. A day holds up to two windows, at least 30 minutes apart.\n\n**Who can edit.** A custom schedule can be edited and deleted by its author or by an administrator of the Bitrix24 account. The `canEdit` field in the response indicates whether the key owner may do so.\n\n**Before run modes are enabled.** The library can always be read. Creating, editing and deleting, like [setting a server's run mode](\u002Fdocs\u002Finfra\u002Flifecycle\u002Frun-mode), return `400 RUN_MODE_UNAVAILABLE` until run modes are enabled for the Bitrix24 account. Until then the library is empty: the presets appear in it together with the run modes.\n\n**Schedule for new machines.** An administrator of the Bitrix24 account can mark the schedule new machines are born on, so a new machine does not have to be moved to a schedule after it is created. There are two marks — one for servers and galaxy applications, one for agents and bots. An agent on a schedule sleeps outside its windows and answers no messages until the next window opens, so agents have a mark of their own. The mark does not touch machines that already exist.\n\nScope: `vibe:infra`\n\n## Operations\n\n- [List schedules](.\u002Fwork-schedules\u002Flist.md) — `GET \u002Fv1\u002Fwork-schedules`\n- [Get a schedule](.\u002Fwork-schedules\u002Fget.md) — `GET \u002Fv1\u002Fwork-schedules\u002F:id`\n- [Create a schedule](.\u002Fwork-schedules\u002Fcreate.md) — `POST \u002Fv1\u002Fwork-schedules`\n- [Update a schedule](.\u002Fwork-schedules\u002Fupdate.md) — `PATCH \u002Fv1\u002Fwork-schedules\u002F:id`\n- [Delete a schedule](.\u002Fwork-schedules\u002Fdelete.md) — `DELETE \u002Fv1\u002Fwork-schedules\u002F:id`\n- [Set the default schedule](.\u002Fwork-schedules\u002Fset-default.md) — `PUT \u002Fv1\u002Fwork-schedules\u002F:id\u002Fdefault`\n\n## Typical scenario\n\n1. Find a matching schedule in the [list](.\u002Fwork-schedules\u002Flist.md) or add a custom one by [creating it](.\u002Fwork-schedules\u002Fcreate.md).\n2. Assign it to a server — [`PATCH \u002Fv1\u002Finfra\u002Fservers\u002F:id\u002Frun-mode`](\u002Fdocs\u002Finfra\u002Flifecycle\u002Frun-mode) with `mode: \"SCHEDULE\"` and `scheduleId`.\n3. Change the windows for all assigned servers at once — [update the schedule](.\u002Fwork-schedules\u002Fupdate.md) with the current `version`.\n4. To have new machines born on the schedule right away, [mark it as the default](.\u002Fwork-schedules\u002Fset-default.md) with `audience: \"machines\"`.\n\n## See also\n\n- [Infrastructure](\u002Fdocs\u002Finfra)\n- [Set the server run mode](\u002Fdocs\u002Finfra\u002Flifecycle\u002Frun-mode)\n- [Scheduled wake](\u002Fdocs\u002Finfra\u002Fwake-schedules)\n","2026-09-24",{"work-schedules\u002Flist.md":7,"work-schedules\u002Fget.md":8,"work-schedules\u002Fcreate.md":9,"work-schedules\u002Fupdate.md":10,"work-schedules\u002Fdelete.md":11,"work-schedules\u002Fset-default.md":12},"## List schedules\n\n`GET \u002Fv1\u002Fwork-schedules`\n\nReturns the work schedule library of the Bitrix24 account — platform presets and custom schedules — with the number of servers assigned to each.\n\n## Parameters\n\nNo parameters. The library of a Bitrix24 account is limited to the platform presets and 50 custom schedules, so filtering and pagination are not provided.\n\n## Examples\n\n### curl — personal key\n\n```bash\ncurl -H \"X-Api-Key: YOUR_API_KEY\" \\\n  https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\n```\n\n### curl — OAuth application\n\n```bash\ncurl -H \"X-Api-Key: YOUR_APP_KEY\" \\\n  -H \"Authorization: Bearer USER_SESSION_TOKEN\" \\\n  https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\n```\n\n### JavaScript — personal key\n\n```javascript\nconst res = await fetch('https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules', {\n  headers: { 'X-Api-Key': 'YOUR_API_KEY' },\n})\nconst { data } = await res.json()\nconst own = data.filter(s => s.kind === 'CUSTOM')\nconsole.log(`Schedules: ${data.length}, custom: ${own.length}`)\n```\n\n### JavaScript — OAuth application\n\n```javascript\nconst res = await fetch('https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules', {\n  headers: {\n    'X-Api-Key': 'YOUR_APP_KEY',\n    'Authorization': 'Bearer USER_SESSION_TOKEN',\n  },\n})\nconst { data } = await res.json()\n```\n\n## Response fields\n\n| Field | Type | Description |\n|------|-----|----------|\n| `success` | boolean | Always `true` on success |\n| `data` | array | Schedules of the Bitrix24 account: presets first, then custom schedules in the order they were created |\n| `data[].id` | string | Schedule ID. Accepted by [setting a server's run mode](\u002Fdocs\u002Finfra\u002Flifecycle\u002Frun-mode) and the other library operations |\n| `data[].kind` | string | `PRESET` — a platform preset, `CUSTOM` — a custom schedule |\n| `data[].name` | string | Name. A preset's name is returned in the key owner's language |\n| `data[].presetKey` | string \\| null | Preset key: `weekdays-9-18`, `weekdays-9-19`, `weekdays-9-20`, `weekdays-8-19`, `weekdays-8-20`, `daily-9-21`. `null` for a custom schedule |\n| `data[].timezone` | string | IANA time zone used to interpret the windows |\n| `data[].windows` | array | Windows `{ isoDay, start, end }` in local time. Window rules are on the [section index](\u002Fdocs\u002Finfra\u002Fwork-schedules) |\n| `data[].version` | number | Version number. Passed to [update](.\u002Fupdate.md) |\n| `data[].canEdit` | boolean | Whether the key owner may edit and delete the schedule. Always `false` for a preset |\n| `data[].assignedCount` | number | How many servers of the Bitrix24 account run on the schedule, other employees' servers included. The servers themselves are not named |\n| `data[].defaultForNewMachines` | boolean | New servers and applications in the Bitrix24 account's galaxy use this schedule when no run mode is specified at creation. At most one schedule has `true`. A Bitrix24 account administrator sets this flag — [Set the default schedule](.\u002Fset-default.md) |\n| `data[].defaultForNewAgents` | boolean | New agents and bots in the Bitrix24 account use this schedule by default. At most one schedule has `true`; this flag is set separately from `defaultForNewMachines` |\n\n## Response example\n\n```json\n{\n  \"success\": true,\n  \"data\": [\n    {\n      \"id\": \"cmfp4qz7x00031ocg5d1a8k2m\",\n      \"kind\": \"PRESET\",\n      \"name\": \"Weekdays 9–18\",\n      \"presetKey\": \"weekdays-9-18\",\n      \"timezone\": \"Europe\u002FBerlin\",\n      \"windows\": [\n        { \"isoDay\": 1, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 2, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 3, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 4, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 5, \"start\": \"09:00\", \"end\": \"18:00\" }\n      ],\n      \"version\": 1,\n      \"canEdit\": false,\n      \"assignedCount\": 3,\n      \"defaultForNewMachines\": false,\n      \"defaultForNewAgents\": false\n    },\n    {\n      \"id\": \"cmfp4r0q2000a1ocg7h2k9x3d\",\n      \"kind\": \"CUSTOM\",\n      \"name\": \"Warehouse shifts\",\n      \"presetKey\": null,\n      \"timezone\": \"Europe\u002FBerlin\",\n      \"windows\": [\n        { \"isoDay\": 1, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 2, \"start\": \"09:00\", \"end\": \"13:00\" },\n        { \"isoDay\": 2, \"start\": \"14:00\", \"end\": \"24:00\" }\n      ],\n      \"version\": 2,\n      \"canEdit\": true,\n      \"assignedCount\": 1,\n      \"defaultForNewMachines\": true,\n      \"defaultForNewAgents\": false\n    }\n  ]\n}\n```\n\n## Error response example\n\n403 — the key lacks the `vibe:infra` scope:\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"INFRA_SCOPE_REQUIRED\",\n    \"message\": \"This API key does not have infrastructure rights (scope vibe:infra).\",\n    \"details\": { \"requiredScope\": \"vibe:infra\" }\n  }\n}\n```\n\n## Errors\n\n| HTTP | Code | Description |\n|------|-----|----------|\n| 401 | `MISSING_API_KEY` | The `X-Api-Key` header is missing |\n| 401 | `INVALID_API_KEY` | The key is not recognized: no such key exists on the platform |\n| 403 | `INFRA_SCOPE_REQUIRED` | The key lacks the `vibe:infra` scope |\n| 403 | `INFRA_FORBIDDEN_FOR_COWORK_KEY` | The call was made with a Cowork key. The schedule library controls servers and their billing, so Cowork keys cannot access it, even for read operations. For the required key, see — [Project key for deploy](\u002Fdocs\u002Fcowork\u002Fdeploy-key) |\n| 404 | `NOT_FOUND` | The key is not bound to a Bitrix24 account |\n| 429 | `RATE_LIMITED` | The limit of 60 requests per minute per key is exceeded. The current limit is returned in the `x-ratelimit-limit` header |\n\nFor the full list of common API errors, see [Errors](\u002Fdocs\u002Ferrors).\n\n## Known specifics\n\n- **The list is empty until run modes are enabled.** The presets are added to the account's library when run modes are enabled, and custom schedules cannot be created before that. An empty `data` for such an account is not an error.\n- **A preset's `name` depends on the key.** The name is not stored in the data — it is translated into the key owner's language, so two keys of the same Bitrix24 account can get different strings. Identify a preset reliably by `presetKey`.\n\n## See also\n\n- [Get a schedule](.\u002Fget.md)\n- [Create a schedule](.\u002Fcreate.md)\n- [Set the server run mode](\u002Fdocs\u002Finfra\u002Flifecycle\u002Frun-mode)\n","## Get a schedule\n\n`GET \u002Fv1\u002Fwork-schedules\u002F:id`\n\nReturns one work schedule from the library of the Bitrix24 account: windows by weekday, time zone, version and the number of assigned servers.\n\n## Parameters\n\n| Parameter | In | Type | Required | Description |\n|----------|---|-----|:-----:|----------|\n| `id` | path | string | yes | Schedule ID. Source — `data[].id` from the [schedule list](.\u002Flist.md) or `workSchedule.id` in [`GET \u002Fv1\u002Finfra\u002Fservers\u002F:id`](\u002Fdocs\u002Finfra\u002Fservers\u002Fget) |\n\n## Examples\n\n### curl — personal key\n\n```bash\ncurl -H \"X-Api-Key: YOUR_API_KEY\" \\\n  https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002FWORK_SCHEDULE_ID\n```\n\n### curl — OAuth application\n\n```bash\ncurl -H \"X-Api-Key: YOUR_APP_KEY\" \\\n  -H \"Authorization: Bearer USER_SESSION_TOKEN\" \\\n  https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002FWORK_SCHEDULE_ID\n```\n\n### JavaScript — personal key\n\n```javascript\nconst res = await fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002F${workScheduleId}`,\n  { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }\n)\nconst { data } = await res.json()\nconsole.log(`${data.name}: ${data.windows.length} windows, ${data.assignedCount} servers`)\n```\n\n### JavaScript — OAuth application\n\n```javascript\nconst res = await fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002F${workScheduleId}`,\n  {\n    headers: {\n      'X-Api-Key': 'YOUR_APP_KEY',\n      'Authorization': 'Bearer USER_SESSION_TOKEN',\n    },\n  }\n)\nconst { data } = await res.json()\n```\n\n## Response fields\n\n| Field | Type | Description |\n|------|-----|----------|\n| `success` | boolean | Always `true` on success |\n| `data.id` | string | Schedule ID |\n| `data.kind` | string | `PRESET` — a platform preset, `CUSTOM` — a custom schedule |\n| `data.name` | string | Name. A preset's name is returned in the key owner's language |\n| `data.presetKey` | string \\| null | Preset key: `weekdays-9-18`, `weekdays-9-19`, `weekdays-9-20`, `weekdays-8-19`, `weekdays-8-20`, `daily-9-21`. `null` for a custom schedule |\n| `data.timezone` | string | IANA time zone used to interpret the time windows |\n| `data.windows` | array | Windows `{ isoDay, start, end }`: `isoDay` from 1 (Monday) to 7, `start` and `end` in local `HH:MM`, the end of the day is `24:00` |\n| `data.version` | number | Version number. Passed to [update](.\u002Fupdate.md) |\n| `data.canEdit` | boolean | Whether the key owner may edit and delete the schedule. Always `false` for a preset |\n| `data.assignedCount` | number | How many servers of the Bitrix24 account run on the schedule, other employees' servers included. The servers themselves are not named |\n| `data.defaultForNewMachines` | boolean | New servers and galaxy applications in the Bitrix24 account use this schedule if no mode is specified when they are created. At most one schedule has `true`. A Bitrix24 account administrator sets this flag — [Set the default schedule](.\u002Fset-default.md) |\n| `data.defaultForNewAgents` | boolean | New agents and bots in the Bitrix24 account use this schedule when they are created. At most one schedule has `true`; this flag is set independently of `defaultForNewMachines` |\n\n## Response example\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"id\": \"cmfp4r0q2000a1ocg7h2k9x3d\",\n    \"kind\": \"CUSTOM\",\n    \"name\": \"Warehouse shifts\",\n    \"presetKey\": null,\n    \"timezone\": \"Europe\u002FBerlin\",\n    \"windows\": [\n      { \"isoDay\": 1, \"start\": \"09:00\", \"end\": \"18:00\" },\n      { \"isoDay\": 2, \"start\": \"09:00\", \"end\": \"13:00\" },\n      { \"isoDay\": 2, \"start\": \"14:00\", \"end\": \"24:00\" }\n    ],\n    \"version\": 2,\n    \"canEdit\": true,\n    \"assignedCount\": 1,\n    \"defaultForNewMachines\": true,\n    \"defaultForNewAgents\": false\n  }\n}\n```\n\n## Error response example\n\n404 — no such schedule in the key's Bitrix24 account:\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"NOT_FOUND\",\n    \"message\": \"Work schedule not found\"\n  }\n}\n```\n\n## Errors\n\n| HTTP | Code | Description |\n|------|-----|----------|\n| 401 | `MISSING_API_KEY` | The `X-Api-Key` header is missing |\n| 401 | `INVALID_API_KEY` | The key is not recognized: no such key exists on the platform |\n| 403 | `INFRA_SCOPE_REQUIRED` | The key lacks the `vibe:infra` scope |\n| 403 | `INFRA_FORBIDDEN_FOR_COWORK_KEY` | The call was made with a Cowork key. The schedule library manages servers and their billing, so Cowork keys cannot access it, including for read operations. For the next steps, see — [Project key for deploy](\u002Fdocs\u002Fcowork\u002Fdeploy-key) |\n| 404 | `NOT_FOUND` | No schedule with this `id` exists in the key's Bitrix24 account, or the key is not bound to a Bitrix24 account. A schedule of another account gets the same answer — the response does not confirm that it exists |\n| 429 | `RATE_LIMITED` | The limit of 60 requests per minute per key is exceeded. The current limit is returned in the `x-ratelimit-limit` header |\n\nFor the full list of common API errors, see [Errors](\u002Fdocs\u002Ferrors).\n\n## See also\n\n- [List schedules](.\u002Flist.md)\n- [Update a schedule](.\u002Fupdate.md)\n- [Delete a schedule](.\u002Fdelete.md)\n","## Create a schedule\n\n`POST \u002Fv1\u002Fwork-schedules`\n\nCreates a custom work schedule in the library of the Bitrix24 account.\n\nThe created schedule is assigned to servers by [setting the run mode](\u002Fdocs\u002Finfra\u002Flifecycle\u002Frun-mode).\n\n## Request fields (body)\n\n| Field | Type | Required | Description |\n|------|-----|:-----:|----------|\n| `name` | string | yes | Name, from 1 to 80 characters. Leading and trailing spaces are trimmed |\n| `timezone` | string | yes | IANA time zone used to interpret the windows, for example `Europe\u002FBerlin` |\n| `windows` | array | yes | Windows `{ isoDay, start, end }`, at most two per day. Window rules are on the [section index](\u002Fdocs\u002Finfra\u002Fwork-schedules) |\n| `windows[].isoDay` | number | yes | Weekday: 1 — Monday, 7 — Sunday |\n| `windows[].start` | string | yes | Window start, local time `HH:MM` in 30-minute increments |\n| `windows[].end` | string | yes | Window end, local time `HH:MM` in 30-minute increments. Midnight is `24:00` |\n\n## Examples\n\n### curl — personal key\n\n```bash\ncurl -X POST https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules \\\n  -H \"X-Api-Key: YOUR_API_KEY\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\n    \"name\": \"Warehouse shifts\",\n    \"timezone\": \"Europe\u002FBerlin\",\n    \"windows\": [\n      { \"isoDay\": 1, \"start\": \"09:00\", \"end\": \"18:00\" },\n      { \"isoDay\": 2, \"start\": \"09:00\", \"end\": \"13:00\" },\n      { \"isoDay\": 2, \"start\": \"14:00\", \"end\": \"24:00\" }\n    ]\n  }'\n```\n\n### curl — OAuth application\n\n```bash\ncurl -X POST https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules \\\n  -H \"X-Api-Key: YOUR_APP_KEY\" \\\n  -H \"Authorization: Bearer USER_SESSION_TOKEN\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\n    \"name\": \"Warehouse shifts\",\n    \"timezone\": \"Europe\u002FBerlin\",\n    \"windows\": [\n      { \"isoDay\": 1, \"start\": \"09:00\", \"end\": \"18:00\" },\n      { \"isoDay\": 2, \"start\": \"09:00\", \"end\": \"13:00\" },\n      { \"isoDay\": 2, \"start\": \"14:00\", \"end\": \"24:00\" }\n    ]\n  }'\n```\n\n### JavaScript — personal key\n\n```javascript\nconst res = await fetch('https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules', {\n  method: 'POST',\n  headers: {\n    'X-Api-Key': 'YOUR_API_KEY',\n    'Content-Type': 'application\u002Fjson',\n  },\n  body: JSON.stringify({\n    name: 'Warehouse shifts',\n    timezone: 'Europe\u002FBerlin',\n    windows: [\n      { isoDay: 1, start: '09:00', end: '18:00' },\n      { isoDay: 2, start: '09:00', end: '13:00' },\n      { isoDay: 2, start: '14:00', end: '24:00' },\n    ],\n  }),\n})\nconst { data } = await res.json()\nconsole.log(`Created schedule ${data.id}`)\n```\n\n### JavaScript — OAuth application\n\n```javascript\nconst res = await fetch('https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules', {\n  method: 'POST',\n  headers: {\n    'X-Api-Key': 'YOUR_APP_KEY',\n    'Authorization': 'Bearer USER_SESSION_TOKEN',\n    'Content-Type': 'application\u002Fjson',\n  },\n  body: JSON.stringify({\n    name: 'Warehouse shifts',\n    timezone: 'Europe\u002FBerlin',\n    windows: [\n      { isoDay: 1, start: '09:00', end: '18:00' },\n      { isoDay: 2, start: '09:00', end: '13:00' },\n      { isoDay: 2, start: '14:00', end: '24:00' },\n    ],\n  }),\n})\nconst { data } = await res.json()\n```\n\n## Response fields\n\nThe response status is `201 Created`.\n\n| Field | Type | Description |\n|------|-----|----------|\n| `success` | boolean | Always `true` on success |\n| `data.id` | string | ID of the created schedule |\n| `data.kind` | string | Always `CUSTOM` |\n| `data.name` | string | Name |\n| `data.presetKey` | null | Always `null` for a custom schedule |\n| `data.timezone` | string | IANA time zone |\n| `data.windows` | array | Windows `{ isoDay, start, end }` ordered by day and time |\n| `data.version` | number | Version number, `1` for a new schedule |\n| `data.canEdit` | boolean | `true`: the author may edit their own schedule |\n| `data.assignedCount` | number | `0`: a new schedule is not assigned to any server yet |\n| `data.defaultForNewMachines` | boolean | `false`: a new schedule is not yet selected as the default for new machines. An administrator of the Bitrix24 account selects the default — [Set the default schedule](.\u002Fset-default.md) |\n| `data.defaultForNewAgents` | boolean | `false`: a new schedule is not yet selected as the default for new agents and bots |\n\n## Response example\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"id\": \"cmfp4r0q2000a1ocg7h2k9x3d\",\n    \"kind\": \"CUSTOM\",\n    \"name\": \"Warehouse shifts\",\n    \"presetKey\": null,\n    \"timezone\": \"Europe\u002FBerlin\",\n    \"windows\": [\n      { \"isoDay\": 1, \"start\": \"09:00\", \"end\": \"18:00\" },\n      { \"isoDay\": 2, \"start\": \"09:00\", \"end\": \"13:00\" },\n      { \"isoDay\": 2, \"start\": \"14:00\", \"end\": \"24:00\" }\n    ],\n    \"version\": 1,\n    \"canEdit\": true,\n    \"assignedCount\": 0,\n    \"defaultForNewMachines\": false,\n    \"defaultForNewAgents\": false\n  }\n}\n```\n\n## Error response example\n\n400 — a window time is not in `HH:MM` format:\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"VALIDATION_ERROR\",\n    \"message\": \"windows.0.end: must be local time HH:MM (24:00 for midnight)\"\n  }\n}\n```\n\n## Errors\n\n| HTTP | Code | Description |\n|------|-----|----------|\n| 400 | `VALIDATION_ERROR` | The body does not match the schema — an unknown field, an empty name, an unknown time zone, a time not in `HH:MM` format — or the windows break the week rules. For a schema violation, `message` carries the field path and the reason. For a week-rule violation, `message` carries the day and the window bounds in minutes from midnight |\n| 400 | `WORK_SCHEDULE_EMPTY` | An empty `windows` array was passed: a server on such a schedule would never run |\n| 400 | `RUN_MODE_UNAVAILABLE` | Run modes are not enabled for the Bitrix24 account yet |\n| 401 | `MISSING_API_KEY` | The `X-Api-Key` header is missing |\n| 401 | `INVALID_API_KEY` | The key is not recognized: no such key exists on the platform |\n| 403 | `WORK_SCHEDULE_LIMIT` | The Bitrix24 account already keeps 50 custom schedules. Delete an unused one or assign a preset |\n| 403 | `WRITE_BLOCKED_READONLY_KEY` | The key is in read-only mode — it cannot create schedules |\n| 403 | `INFRA_SCOPE_REQUIRED` | The key lacks the `vibe:infra` scope |\n| 403 | `INFRA_FORBIDDEN_FOR_COWORK_KEY` | The call was made with a Cowork key, which cannot access the schedule library. For instructions, see [Project deploy key](\u002Fdocs\u002Fcowork\u002Fdeploy-key) |\n| 404 | `NOT_FOUND` | The key is not bound to a Bitrix24 account |\n| 429 | `RATE_LIMITED` | The limit of 20 requests per minute per key is exceeded. The current limit is returned in the `x-ratelimit-limit` header |\n\nFor the full list of common API errors, see [Errors](\u002Fdocs\u002Ferrors).\n\n## Known specifics\n\n- **The author is the key owner.** The schedule's author is recorded as the key owner, not the user of an OAuth application session. The key owner and an administrator of the Bitrix24 account can then edit and delete the schedule.\n- **Presets do not count toward the limit.** The limit of 50 schedules counts custom schedules only — platform presets do not take up any of it.\n\n## See also\n\n- [List schedules](.\u002Flist.md)\n- [Update a schedule](.\u002Fupdate.md)\n- [Set the server run mode](\u002Fdocs\u002Finfra\u002Flifecycle\u002Frun-mode)\n","## Update a schedule\n\n`PATCH \u002Fv1\u002Fwork-schedules\u002F:id`\n\nChanges the name, time zone or windows of a custom schedule. The library is shared across the Bitrix24 account, so new windows apply at once to every server assigned to the schedule, and the edit carries a version number so as not to overwrite someone else's edit.\n\n## Parameters\n\n| Parameter | In | Type | Required | Description |\n|----------|---|-----|:-----:|----------|\n| `id` | path | string | yes | ID of a custom schedule. Source — `data[].id` from the [schedule list](.\u002Flist.md) |\n\n## Request fields (body)\n\n| Field | Type | Required | Description |\n|------|-----|:-----:|----------|\n| `version` | number | yes | The version you read. Source — `version` in the [list](.\u002Flist.md) or in [Get a schedule](.\u002Fget.md) |\n| `name` | string | no | New name, from 1 to 80 characters |\n| `timezone` | string | no | New IANA time zone |\n| `windows` | array | no | New windows `{ isoDay, start, end }` — they replace the previous ones entirely. For the window rules, see the [section index](\u002Fdocs\u002Finfra\u002Fwork-schedules) |\n\n## Examples\n\n### curl — personal key\n\n```bash\ncurl -X PATCH https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002FWORK_SCHEDULE_ID \\\n  -H \"X-Api-Key: YOUR_API_KEY\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\n    \"version\": 2,\n    \"windows\": [\n      { \"isoDay\": 1, \"start\": \"08:00\", \"end\": \"17:00\" },\n      { \"isoDay\": 2, \"start\": \"08:00\", \"end\": \"17:00\" }\n    ]\n  }'\n```\n\n### curl — OAuth application\n\n```bash\ncurl -X PATCH https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002FWORK_SCHEDULE_ID \\\n  -H \"X-Api-Key: YOUR_APP_KEY\" \\\n  -H \"Authorization: Bearer USER_SESSION_TOKEN\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{\n    \"version\": 2,\n    \"windows\": [\n      { \"isoDay\": 1, \"start\": \"08:00\", \"end\": \"17:00\" },\n      { \"isoDay\": 2, \"start\": \"08:00\", \"end\": \"17:00\" }\n    ]\n  }'\n```\n\n### JavaScript — personal key\n\n```javascript\nconst res = await fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002F${workScheduleId}`,\n  {\n    method: 'PATCH',\n    headers: {\n      'X-Api-Key': 'YOUR_API_KEY',\n      'Content-Type': 'application\u002Fjson',\n    },\n    body: JSON.stringify({\n      version: 2,\n      windows: [\n        { isoDay: 1, start: '08:00', end: '17:00' },\n        { isoDay: 2, start: '08:00', end: '17:00' },\n      ],\n    }),\n  }\n)\nconst body = await res.json()\nconsole.log(`Version ${body.data.version}, servers affected: ${body.affectedServers}`)\n```\n\n### JavaScript — OAuth application\n\n```javascript\nconst res = await fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002F${workScheduleId}`,\n  {\n    method: 'PATCH',\n    headers: {\n      'X-Api-Key': 'YOUR_APP_KEY',\n      'Authorization': 'Bearer USER_SESSION_TOKEN',\n      'Content-Type': 'application\u002Fjson',\n    },\n    body: JSON.stringify({\n      version: 2,\n      windows: [\n        { isoDay: 1, start: '08:00', end: '17:00' },\n        { isoDay: 2, start: '08:00', end: '17:00' },\n      ],\n    }),\n  }\n)\nconst body = await res.json()\n```\n\n## Response fields\n\n| Field | Type | Description |\n|------|-----|----------|\n| `success` | boolean | Always `true` on success |\n| `data` | object | The schedule after the edit — the same shape as in [Get a schedule](.\u002Fget.md) |\n| `data.version` | number | The new version: every successful edit raises it by one |\n| `affectedServers` | number | How many servers of the Bitrix24 account run on the schedule after the edit, other employees' servers included |\n\n## Response example\n\n```json\n{\n  \"success\": true,\n  \"data\": {\n    \"id\": \"cmfp4r0q2000a1ocg7h2k9x3d\",\n    \"kind\": \"CUSTOM\",\n    \"name\": \"Warehouse shifts\",\n    \"presetKey\": null,\n    \"timezone\": \"Europe\u002FBerlin\",\n    \"windows\": [\n      { \"isoDay\": 1, \"start\": \"08:00\", \"end\": \"17:00\" },\n      { \"isoDay\": 2, \"start\": \"08:00\", \"end\": \"17:00\" }\n    ],\n    \"version\": 3,\n    \"canEdit\": true,\n    \"assignedCount\": 1,\n    \"defaultForNewMachines\": true,\n    \"defaultForNewAgents\": false\n  },\n  \"affectedServers\": 1\n}\n```\n\n## Error response example\n\n409 — the schedule was changed after you read it:\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"WORK_SCHEDULE_STALE\",\n    \"message\": \"The work schedule was changed by someone else — reload it and repeat the edit\"\n  }\n}\n```\n\n## Errors\n\n| HTTP | Code | Description |\n|------|-----|----------|\n| 400 | `VALIDATION_ERROR` | The body does not match the schema — a missing `version`, an unknown field, an unknown time zone — or the windows violate the rules for weekly schedules. For a schema violation, `message` carries the field path and the reason. For a week-rule violation, `message` carries the day and the window bounds in minutes from midnight |\n| 400 | `WORK_SCHEDULE_EMPTY` | An empty `windows` was passed: servers on such a schedule would never run |\n| 400 | `RUN_MODE_UNAVAILABLE` | Run modes are not enabled for the Bitrix24 account yet |\n| 401 | `MISSING_API_KEY` | The `X-Api-Key` header is missing |\n| 401 | `INVALID_API_KEY` | The key is not recognized: no such key exists on the platform |\n| 403 | `WORK_SCHEDULE_PRESET_READONLY` | The schedule is a preset — it cannot be edited. For a different week, [create a custom one](.\u002Fcreate.md) |\n| 403 | `WORK_SCHEDULE_EDIT_FORBIDDEN` | Only the author or an administrator of the Bitrix24 account may edit the schedule |\n| 403 | `WRITE_BLOCKED_READONLY_KEY` | The key is in read-only mode — it cannot edit schedules |\n| 403 | `INFRA_SCOPE_REQUIRED` | The key lacks the `vibe:infra` scope |\n| 403 | `INFRA_FORBIDDEN_FOR_COWORK_KEY` | The call was made with a Cowork key, which cannot access the schedule library. For guidance, see [Project deploy key](\u002Fdocs\u002Fcowork\u002Fdeploy-key) |\n| 404 | `NOT_FOUND` | No schedule with this `id` exists in the key's Bitrix24 account, or the key is not bound to a Bitrix24 account |\n| 409 | `WORK_SCHEDULE_STALE` | The version in the request is out of date: the schedule was changed after you read it. Read it again and repeat the edit with the new `version` |\n| 429 | `RATE_LIMITED` | The limit of 30 requests per minute per key is exceeded. The effective value is in the `x-ratelimit-limit` header |\n\nFor the full list of common API errors, see [Errors](\u002Fdocs\u002Ferrors).\n\n## Known specifics\n\n- **Editing windows or the time zone rebuilds the wake-ups of every assigned server.** The new windows, the recomputed wake-ups of each server on the schedule and the new version are written as one operation: if the operation fails, nothing changes. A name-only edit does not touch the wake-ups.\n- **Server costs change with the windows.** A server on the schedule runs during its windows, so a longer week raises the cost of every assigned server, other employees' servers included — the number of assigned servers is returned in `affectedServers`.\n\n## See also\n\n- [Get a schedule](.\u002Fget.md)\n- [Create a schedule](.\u002Fcreate.md)\n- [Delete a schedule](.\u002Fdelete.md)\n","## Delete a schedule\n\n`DELETE \u002Fv1\u002Fwork-schedules\u002F:id`\n\nDeletes a custom schedule from the library of the Bitrix24 account. A schedule that servers run on is deleted only with consent to move them to another run mode. A deleted schedule cannot be restored through the API — create a new one if needed.\n\n## Parameters\n\n| Parameter | In | Type | Required | Description |\n|----------|---|-----|:-----:|----------|\n| `id` | path | string | yes | ID of a custom schedule. Source — `data[].id` from the [schedule list](.\u002Flist.md) |\n| `reassign` | query | string | no | `true` — consent to release the servers from the schedule before deleting it. An agent or bot switches to `ALWAYS`, and its remembered idle threshold is cleared. An application with `idleSleepProtected: true` switches to an effective run mode of `ALWAYS` while retaining its remembered threshold. All other applications go to `IDLE` with their own threshold, or with 60 minutes if they have none. Any other value is treated as a refusal |\n\n## Examples\n\n### curl — personal key\n\n```bash\ncurl -X DELETE \"https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002FWORK_SCHEDULE_ID?reassign=true\" \\\n  -H \"X-Api-Key: YOUR_API_KEY\"\n```\n\n### curl — OAuth application\n\n```bash\ncurl -X DELETE \"https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002FWORK_SCHEDULE_ID?reassign=true\" \\\n  -H \"X-Api-Key: YOUR_APP_KEY\" \\\n  -H \"Authorization: Bearer USER_SESSION_TOKEN\"\n```\n\n### JavaScript — personal key\n\n```javascript\nconst res = await fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002F${workScheduleId}?reassign=true`,\n  { method: 'DELETE', headers: { 'X-Api-Key': 'YOUR_API_KEY' } }\n)\nif (res.status === 204) {\n  console.log('Schedule deleted')\n}\n```\n\n### JavaScript — OAuth application\n\n```javascript\nconst res = await fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002F${workScheduleId}?reassign=true`,\n  {\n    method: 'DELETE',\n    headers: {\n      'X-Api-Key': 'YOUR_APP_KEY',\n      'Authorization': 'Bearer USER_SESSION_TOKEN',\n    },\n  }\n)\nif (res.status === 204) {\n  console.log('Schedule deleted')\n}\n```\n\n## Response\n\nA successful delete returns HTTP status `204 No Content` with an empty body. Success is signaled by the status code, not the content. The new run modes of the moved servers are read from [`GET \u002Fv1\u002Finfra\u002Fservers\u002F:id`](\u002Fdocs\u002Finfra\u002Fservers\u002Fget).\n\n## Response example\n\n```\nHTTP\u002F1.1 204 No Content\n```\n\n## Error response example\n\n409 — servers run on the schedule, and `reassign=true` was not passed:\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"WORK_SCHEDULE_IN_USE\",\n    \"message\": \"The work schedule is assigned to servers: repeat with reassign=true to move them to another run mode and delete it\",\n    \"details\": { \"assignedCount\": 2 }\n  }\n}\n```\n\n## Errors\n\n| HTTP | Code | Description |\n|------|-----|----------|\n| 400 | `RUN_MODE_UNAVAILABLE` | Run modes are not enabled for the Bitrix24 account yet |\n| 401 | `MISSING_API_KEY` | The `X-Api-Key` header is missing |\n| 401 | `INVALID_API_KEY` | The key is not recognized: no such key exists on the platform |\n| 403 | `WORK_SCHEDULE_PRESET_READONLY` | The schedule is a preset — it cannot be deleted |\n| 403 | `WORK_SCHEDULE_EDIT_FORBIDDEN` | Only the author or an administrator of the Bitrix24 account may delete the schedule |\n| 403 | `WRITE_BLOCKED_READONLY_KEY` | The key is in read-only mode — it cannot delete schedules |\n| 403 | `INFRA_SCOPE_REQUIRED` | The key lacks the `vibe:infra` scope |\n| 403 | `INFRA_FORBIDDEN_FOR_COWORK_KEY` | The call was made with a Cowork key, which cannot access the schedule library. For instructions, see [Project key for deploy](\u002Fdocs\u002Fcowork\u002Fdeploy-key) |\n| 404 | `NOT_FOUND` | No schedule with this `id` exists in the key's Bitrix24 account, or the key is not bound to a Bitrix24 account |\n| 409 | `WORK_SCHEDULE_IN_USE` | Servers run on the schedule, and `reassign=true` was not passed. The number of servers is in `error.details.assignedCount`. The same response is returned if a server is assigned to the schedule during the delete — repeat the request |\n| 429 | `RATE_LIMITED` | The limit of 10 requests per minute per key is exceeded. The current limit is returned in the `x-ratelimit-limit` header |\n\nFor the full list of shared API errors, see [Errors](\u002Fdocs\u002Ferrors).\n\n## Known specifics\n\n- **The move affects other employees' servers too.** With `reassign=true` every server on the schedule moves to another run mode, not only the key owner's — and its cost changes along with the mode.\n- **Deleted servers do not block the delete.** Servers that are already deleted are not counted in `assignedCount` and are taken off the schedule without consent.\n\n## See also\n\n- [List schedules](.\u002Flist.md)\n- [Update a schedule](.\u002Fupdate.md)\n- [Set the server run mode](\u002Fdocs\u002Finfra\u002Flifecycle\u002Frun-mode)\n","## Set the default schedule\n\n`PUT \u002Fv1\u002Fwork-schedules\u002F:id\u002Fdefault`\n\nSets or clears the default work schedule for new machines in the Bitrix24 account. Machines that already exist keep their mode.\n\nThere are two marks, set independently: `machines` for new servers and galaxy applications, `agents` for new agents and bots. An agent on a schedule sleeps outside its windows and answers no messages until the next window opens, so agents have a mark of their own. Each mark can be set on at most one schedule: setting it on a new schedule removes it from the previous one.\n\nOnly an administrator of the Bitrix24 account can set or remove the mark — it changes the mode of every employee's new machines, and their bill with it. The administrator check applies to the owner of a personal key, so a call with an OAuth application key is refused with `403 ADMIN_ONLY` even with an administrator's session. The examples below use a personal key only.\n\n## Parameters\n\n| Parameter | In | Type | Required | Description |\n|----------|---|-----|:-----:|----------|\n| `id` | path | string | yes | Schedule ID — a preset or a custom one. Source — `data[].id` from the [schedule list](.\u002Flist.md) |\n\n## Request fields (body)\n\n| Field | Type | Required | Description |\n|------|-----|:-----:|----------|\n| `audience` | string | yes | Which mark: `machines` — new servers and galaxy applications, `agents` — new agents and bots |\n| `enabled` | boolean | yes | `true` sets the mark on this schedule, `false` removes it from this schedule |\n\n## Examples\n\n### curl — personal key\n\n```bash\ncurl -X PUT https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002FWORK_SCHEDULE_ID\u002Fdefault \\\n  -H \"X-Api-Key: YOUR_API_KEY\" \\\n  -H \"Content-Type: application\u002Fjson\" \\\n  -d '{ \"audience\": \"machines\", \"enabled\": true }'\n```\n\n### JavaScript — personal key\n\n```javascript\nconst res = await fetch(\n  `https:\u002F\u002Fvibecode.bitrix24.com\u002Fv1\u002Fwork-schedules\u002F${workScheduleId}\u002Fdefault`,\n  {\n    method: 'PUT',\n    headers: {\n      'X-Api-Key': 'YOUR_API_KEY',\n      'Content-Type': 'application\u002Fjson',\n    },\n    body: JSON.stringify({ audience: 'machines', enabled: true }),\n  }\n)\nconst { data } = await res.json()\nconst marked = data.find(s => s.defaultForNewMachines)\nconsole.log(`New machines use this schedule: ${marked ? marked.name : 'no schedule marked'}`)\n```\n\n## Response fields\n\n| Field | Type | Description |\n|------|-----|----------|\n| `success` | boolean | Always `true` on success |\n| `data` | array | The whole schedule library of the Bitrix24 account after the change: the mark may have moved from one schedule to another. Each item has the same shape as in the [schedule list](.\u002Flist.md) |\n| `data[].defaultForNewMachines` | boolean | New servers and galaxy applications use this schedule when created. At most one schedule has `true` |\n| `data[].defaultForNewAgents` | boolean | New agents and bots use this schedule when created. At most one schedule has `true` |\n\n## Response example\n\nThe mark for machines is set on the \"Warehouse shifts\" schedule and appears on it alone in the response:\n\n```json\n{\n  \"success\": true,\n  \"data\": [\n    {\n      \"id\": \"cmfp4qz7x00031ocg5d1a8k2m\",\n      \"kind\": \"PRESET\",\n      \"name\": \"Weekdays 9–18\",\n      \"presetKey\": \"weekdays-9-18\",\n      \"timezone\": \"Europe\u002FBerlin\",\n      \"windows\": [\n        { \"isoDay\": 1, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 2, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 3, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 4, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 5, \"start\": \"09:00\", \"end\": \"18:00\" }\n      ],\n      \"version\": 1,\n      \"canEdit\": false,\n      \"assignedCount\": 3,\n      \"defaultForNewMachines\": false,\n      \"defaultForNewAgents\": false\n    },\n    {\n      \"id\": \"cmfp4r0q2000a1ocg7h2k9x3d\",\n      \"kind\": \"CUSTOM\",\n      \"name\": \"Warehouse shifts\",\n      \"presetKey\": null,\n      \"timezone\": \"Europe\u002FBerlin\",\n      \"windows\": [\n        { \"isoDay\": 1, \"start\": \"09:00\", \"end\": \"18:00\" },\n        { \"isoDay\": 2, \"start\": \"09:00\", \"end\": \"13:00\" },\n        { \"isoDay\": 2, \"start\": \"14:00\", \"end\": \"24:00\" }\n      ],\n      \"version\": 2,\n      \"canEdit\": true,\n      \"assignedCount\": 1,\n      \"defaultForNewMachines\": true,\n      \"defaultForNewAgents\": false\n    }\n  ]\n}\n```\n\n## Error response example\n\n403 — the key owner is not an administrator of the Bitrix24 account:\n\n```json\n{\n  \"success\": false,\n  \"error\": {\n    \"code\": \"ADMIN_ONLY\",\n    \"message\": \"Only a Bitrix24 account administrator can choose the schedule new machines are born with\"\n  }\n}\n```\n\n## Errors\n\n| HTTP | Code | Description |\n|------|-----|----------|\n| 400 | `VALIDATION_ERROR` | The body does not match the schema: `audience` or `enabled` is missing, `audience` is neither `machines` nor `agents`, `enabled` is neither `true` nor `false`, or the body carries an extra field. `message` carries the field path and the reason |\n| 400 | `WORK_SCHEDULE_EMPTY` | The schedule has no windows: a machine on it would never run. Removing the mark from such a schedule is allowed |\n| 400 | `RUN_MODE_UNAVAILABLE` | Run modes are not enabled for the Bitrix24 account yet |\n| 401 | `MISSING_API_KEY` | The `X-Api-Key` header is missing |\n| 401 | `INVALID_API_KEY` | The key is not recognized: no such key exists on the platform |\n| 403 | `ADMIN_ONLY` | The key owner is not an administrator of the Bitrix24 account, or the call was made with an OAuth application key |\n| 403 | `WRITE_BLOCKED_READONLY_KEY` | The key is in read-only mode — it cannot set or remove the mark |\n| 403 | `INFRA_SCOPE_REQUIRED` | The key lacks the `vibe:infra` scope |\n| 403 | `INFRA_FORBIDDEN_FOR_COWORK_KEY` | The call was made with a Cowork key — the schedule library is unavailable to this key. For instructions, see [Project key for deploy](\u002Fdocs\u002Fcowork\u002Fdeploy-key) |\n| 404 | `NOT_FOUND` | No schedule with this `id` exists in the key's Bitrix24 account, or the key is not bound to a Bitrix24 account. A schedule of another account gets the same answer — the response does not confirm that it exists |\n| 429 | `RATE_LIMITED` | The limit of 30 requests per minute per key is exceeded. The current limit is returned in the `x-ratelimit-limit` header |\n\nFor the full list of common API errors, see [Errors](\u002Fdocs\u002Ferrors).\n\n## Known specifics\n\n- **An explicit mode at creation takes precedence over the mark.** A server created with a `runMode` block uses the specified mode, including an explicitly specified `IDLE` mode. The mark applies only when the create request names no mode — [Create a server](\u002Fdocs\u002Finfra\u002Fservers\u002Fcreate).\n- **The mark never blocks creation.** If the marked schedule cannot be applied, the machine is created in the mode it would have used without the mark, and creation is not rejected. The mode the machine got is in the `runMode` and `workSchedule` fields of [`GET \u002Fv1\u002Finfra\u002Fservers\u002F:id`](\u002Fdocs\u002Finfra\u002Fservers\u002Fget).\n- **Which machines use the default schedule when created.** The `machines` mark goes to a server created in the Vibecode dashboard or through `POST \u002Fv1\u002Finfra\u002Fservers`, and to a galaxy application. The `agents` mark goes to a machine the platform creates for an agent or a managed bot. A galaxy host gets no mark: it has no mode of its own and runs while any of its applications runs.\n- **Repeating the call changes nothing.** A mark the schedule already carries can be set again — the answer is the same `200`. Removing the mark from a schedule that does not carry it also answers `200` and leaves the mark on another schedule untouched.\n- **One schedule can carry both marks.** The `machines` and `agents` marks are independent: they can sit on one schedule or on different ones.\n- **Deleting a schedule removes its marks.** After a marked schedule is [deleted](.\u002Fdelete.md), new machines are created as they would be without the mark.\n\n## See also\n\n- [List schedules](.\u002Flist.md)\n- [Set the server run mode](\u002Fdocs\u002Finfra\u002Flifecycle\u002Frun-mode)\n- [Create a server](\u002Fdocs\u002Finfra\u002Fservers\u002Fcreate)\n",1794739578271]