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

Marks the work schedule that new machines of the Bitrix24 account are born on, or removes that mark. 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 sits on at most one schedule: set on a new schedule, it moves off 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
id path string yes Schedule ID — a preset or a custom one. Source — data[].id from the schedule list

Request fields (body)

Field Type Required Description
audience string yes Which mark: machines — new servers and galaxy applications, agents — new agents and bots
enabled boolean yes true sets the mark on this schedule, false removes it from this schedule

Examples

curl — personal key

Terminal
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

javascript
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 are born on: ${marked ? marked.name : 'no schedule marked'}`)

Response fields

Field Type Description
success boolean Always true on success
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
data[].defaultForNewMachines boolean New servers and galaxy applications are born on this schedule. At most one schedule has true
data[].defaultForNewAgents boolean New agents and bots are born on this schedule. 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:

JSON
{
  "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:

JSON
{
  "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
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
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
400 RUN_MODE_UNAVAILABLE Run modes are not enabled for the Bitrix24 account yet
401 MISSING_API_KEY The X-Api-Key header is missing
401 INVALID_API_KEY The key is not recognized: no such key exists on the platform
403 ADMIN_ONLY The key owner is not an administrator of the Bitrix24 account, or the call was made with an OAuth application key
403 WRITE_BLOCKED_READONLY_KEY The key is in read-only mode — it cannot set or remove the mark
403 INFRA_SCOPE_REQUIRED The key lacks the vibe:infra scope
403 INFRA_FORBIDDEN_FOR_COWORK_KEY The call was made with a Cowork/Code key — the schedule library is closed to such a key. What to do — Project key for deploy
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
429 RATE_LIMITED The limit of 30 requests per minute per key is exceeded. The exact value is in the x-ratelimit-limit header (the ceiling is split between replicas)

Full list of common API errors — Errors.

Known specifics

  • An explicit mode at creation takes precedence over the mark. A server whose create request carries a runMode block is born in the mode it names, an explicit IDLE included. 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 born in the mode it would have had without the mark, and the creation is not refused. The mode the machine got is in the runMode and workSchedule fields of GET /v1/infra/servers/:id.
  • Which machines get the mark at birth. The machines mark goes to a server created in the Vibecode dashboard or through POST /v1/infra/servers, 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.
  • 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.
  • One schedule can carry both marks. The machines and agents marks 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 born the same way as without the mark.

See also