API changes: July 22, 2026

← Changelog · July 2026

BC-0722-1: server icon is now served as PNG

Old format supported until: 21.07.2026

The server icon is now served as a 256×256 PNG (Content-Type: image/png) — the platform renders it from your uploaded SVG. The upload endpoint (POST /v1/infra/servers/:id/icon) still only accepts SVG, and may now return 400 ICON_RASTERIZE_FAILED when the file can't be rasterized to PNG.

NEW-0722-2: scheduled wake (wake-schedules) is now available on every Bitrix24 account

The wake-window CRUD — GET|POST /v1/infra/servers/:id/wake-schedules, PATCH|DELETE /v1/infra/servers/:id/wake-schedules/:scheduleId — is now available on every Bitrix24 account for standalone servers (kind: "STANDALONE"): the call no longer returns 403 WAKE_SCHEDULE_DISABLED. The platform brings a sleeping server up by a given cron-expressed moment, and the task itself is fired by the app's own cron once the machine is already up. Galaxy apps (kind: "GALAXY_APP") are not part of this rollout yet and still return 403 WAKE_SCHEDULE_GALAXY_DISABLED. The GET /v1/infra/servers/:id response and the server list now include the additive fields nextScheduledWakeAt (the next scheduled wake time, ISO 8601 or null) and wakeScheduleCapable — existing fields are unchanged.

NEW-0722-3: deploy 409 SERVER_NOT_READY now signals it is retryable

POST /v1/infra/servers/:id/deploy now adds error.retryable: true, error.retryAfter (seconds) and a Retry-After header to the 409 SERVER_NOT_READY response returned when the server is already restoring its connection (a repair started by a concurrent deploy or repair). It is a machine signal that retrying is worthwhile: wait the given interval and re-issue the deploy. Existing clients are unaffected — the error code and message are unchanged, the fields are additive.

NEW-0722-4: New endpoint to activate the Marketplace trial for the key's Bitrix24 account

POST /v1/portals/:id/activate-market-trial activates the one-time Bitrix24 Marketplace trial for the Bitrix24 account the calling key belongs to. Previously activation was only possible from the Vibecode dashboard — API keys had no programmatic path.

:id must match the key's account, otherwise 403 PORTAL_MISMATCH. No request body. Rate-limited to 3 requests per hour per account.

Success response: { "success": true, "data": { "status": "activated", "trialEndsAt": "..." } } (or "status": "already_active" when the trial/access already exists). Errors: 403 WRITE_BLOCKED_READONLY_KEY (read-only key), 403 PURPOSE_KEY_FORBIDDEN (special-purpose key may not activate the trial), 404 NOT_FOUND (account not found), 409 ALREADY_ACTIVATED (trial already activated), 409 TRIAL_ACTIVATION_UNAVAILABLE (trial not available for this account), 503 TRIAL_ACTIVATION_RETRY (transient error, retry later).

FIX-0722-5: the Bitrix24 plan probe no longer stops at a scope-limited developer key

Before

On an account with several developer-key holders the plan state could stay unread: if the first probed key answered with account data but without the full licence block (a scope-limited key), the probe stopped there and never reached a key able to read the rest. The plan state stayed unknown, so an account entitled to create servers could receive 402 from POST /v1/infra/servers while GET /v1/me reported capabilities.servers.create.available: false. Calling GET /v1/me?refresh=tariff did not clear the denial.

After

The probe keeps going until a key returns the full licence block. An entitled account is allowed to create servers and capabilities.servers.create.available becomes true. Response shapes are unchanged and no client action is required. The state refreshes with the account's next plan refresh (within an hour) or immediately via GET /v1/me?refresh=tariff.

Integrator impact

No action required. A client branching on 402 at server creation keeps working — on affected accounts that response simply stops arriving.

FIX-0722-6: the `region` field in infrastructure responses always returns a region id

Before

For a server created and running on the international segment, GET /v1/infra/servers and GET /v1/infra/servers/:id could return an internal placement-zone identifier in the region field rather than a catalog region id. The value matched no id in GET /v1/infra/providers/:providerId/regions, so a server could not be matched to its catalog region through that field, and it exposed internal placement detail.

After

region always carries a neutral region id from the same namespace as the catalog — for example bc-eu-central. The value equals the id of the corresponding GET /v1/infra/providers/:providerId/regions entry, so a server maps to its catalog region directly. The placement zone is an internal detail: server creation takes a region, and the platform picks the zone inside it.

What integrators should do

Nothing, if you pass a region value taken from the regions catalog — that flow is unchanged. If your code compared a server response's region against a string obtained earlier from a server response rather than from the catalog, that comparison is now reliable: both ends are in one namespace. Identifiers from the previous catalog are still accepted on input.