For AI agents: markdown of this page — /docs-content-en/infra/work-schedules/set-default.md documentation index — /llms.txt
Set the default schedule
PUT /v1/work-schedules/:id/default
Sets or clears the default work schedule for new machines in the Bitrix24 account. Machines that already exist keep their mode.
There 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.
Only 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.
Parameters
| Parameter | In | Type | Required | Description |
|---|---|---|---|---|
Parameterid |
Inpath | Typestring | Requiredyes | DescriptionSchedule ID — a preset or a custom one. Source — data[].id from the schedule list |
Request fields (body)
| Field | Type | Required | Description |
|---|---|---|---|
Fieldaudience |
Typestring | Requiredyes | DescriptionWhich mark: machines — new servers and galaxy applications, agents — new agents and bots |
Fieldenabled |
Typeboolean | Requiredyes | Descriptiontrue sets the mark on this schedule, false removes it from this schedule |
Examples
curl — personal key
curl -X PUT https://vibecode.bitrix24.com/v1/work-schedules/WORK_SCHEDULE_ID/default \
-H "X-Api-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "audience": "machines", "enabled": true }'
JavaScript — personal key
const res = await fetch(
`https://vibecode.bitrix24.com/v1/work-schedules/${workScheduleId}/default`,
{
method: 'PUT',
headers: {
'X-Api-Key': 'YOUR_API_KEY',
'Content-Type': 'application/json',
},
body: JSON.stringify({ audience: 'machines', enabled: true }),
}
)
const { data } = await res.json()
const marked = data.find(s => s.defaultForNewMachines)
console.log(`New machines use this schedule: ${marked ? marked.name : 'no schedule marked'}`)
Response fields
| Field | Type | Description |
|---|---|---|
Fieldsuccess |
Typeboolean | DescriptionAlways true on success |
Fielddata |
Typearray | DescriptionThe 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 |
Fielddata[].defaultForNewMachines |
Typeboolean | DescriptionNew servers and galaxy applications use this schedule when created. At most one schedule has true |
Fielddata[].defaultForNewAgents |
Typeboolean | DescriptionNew agents and bots use this schedule when created. At most one schedule has true |
Response example
The mark for machines is set on the "Warehouse shifts" schedule and appears on it alone in the response:
{
"success": true,
"data": [
{
"id": "cmfp4qz7x00031ocg5d1a8k2m",
"kind": "PRESET",
"name": "Weekdays 9–18",
"presetKey": "weekdays-9-18",
"timezone": "Europe/Berlin",
"windows": [
{ "isoDay": 1, "start": "09:00", "end": "18:00" },
{ "isoDay": 2, "start": "09:00", "end": "18:00" },
{ "isoDay": 3, "start": "09:00", "end": "18:00" },
{ "isoDay": 4, "start": "09:00", "end": "18:00" },
{ "isoDay": 5, "start": "09:00", "end": "18:00" }
],
"version": 1,
"canEdit": false,
"assignedCount": 3,
"defaultForNewMachines": false,
"defaultForNewAgents": false
},
{
"id": "cmfp4r0q2000a1ocg7h2k9x3d",
"kind": "CUSTOM",
"name": "Warehouse shifts",
"presetKey": null,
"timezone": "Europe/Berlin",
"windows": [
{ "isoDay": 1, "start": "09:00", "end": "18:00" },
{ "isoDay": 2, "start": "09:00", "end": "13:00" },
{ "isoDay": 2, "start": "14:00", "end": "24:00" }
],
"version": 2,
"canEdit": true,
"assignedCount": 1,
"defaultForNewMachines": true,
"defaultForNewAgents": false
}
]
}
Error response example
403 — the key owner is not an administrator of the Bitrix24 account:
{
"success": false,
"error": {
"code": "ADMIN_ONLY",
"message": "Only a Bitrix24 account administrator can choose the schedule new machines are born with"
}
}
Errors
| HTTP | Code | Description |
|---|---|---|
| HTTP400 | CodeVALIDATION_ERROR |
DescriptionThe 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 |
| HTTP400 | CodeWORK_SCHEDULE_EMPTY |
DescriptionThe schedule has no windows: a machine on it would never run. Removing the mark from such a schedule is allowed |
| HTTP400 | CodeRUN_MODE_UNAVAILABLE |
DescriptionRun modes are not enabled for the Bitrix24 account yet |
| HTTP401 | CodeMISSING_API_KEY |
DescriptionThe X-Api-Key header is missing |
| HTTP401 | CodeINVALID_API_KEY |
DescriptionThe key is not recognized: no such key exists on the platform |
| HTTP403 | CodeADMIN_ONLY |
DescriptionThe key owner is not an administrator of the Bitrix24 account, or the call was made with an OAuth application key |
| HTTP403 | CodeWRITE_BLOCKED_READONLY_KEY |
DescriptionThe key is in read-only mode — it cannot set or remove the mark |
| HTTP403 | CodeINFRA_SCOPE_REQUIRED |
DescriptionThe key lacks the vibe:infra scope |
| HTTP403 | CodeINFRA_FORBIDDEN_FOR_COWORK_KEY |
DescriptionThe call was made with a Cowork key — the schedule library is unavailable to this key. For instructions, see Project key for deploy |
| HTTP404 | CodeNOT_FOUND |
DescriptionNo 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 |
| HTTP429 | CodeRATE_LIMITED |
DescriptionThe limit of 30 requests per minute per key is exceeded. The current limit is returned in the x-ratelimit-limit header |
For the full list of common API errors, see Errors.
Known specifics
- An explicit mode at creation takes precedence over the mark. A server created with a
runModeblock uses the specified mode, including an explicitly specifiedIDLEmode. The mark applies only when the create request names no mode — Create a server. - 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
runModeandworkSchedulefields ofGET /v1/infra/servers/:id. - Which machines use the default schedule when created. The
machinesmark goes to a server created in the Vibecode dashboard or throughPOST /v1/infra/servers, and to a galaxy application. Theagentsmark 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. - 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 answers200and leaves the mark on another schedule untouched. - One schedule can carry both marks. The
machinesandagentsmarks are independent: they can sit on one schedule or on different ones. - Deleting a schedule removes its marks. After a marked schedule is deleted, new machines are created as they would be without the mark.