# API changes: July 22, 2026

[← Changelog](/docs/changelog) · [July 2026](/docs/changelog/2026-07)

### 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](/docs/infra/wake-schedules/list), [PATCH|DELETE /v1/infra/servers/:id/wake-schedules/:scheduleId](/docs/infra/wake-schedules/update) — 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](/docs/infra/deploy/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](/docs/infra) 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](/docs/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](/docs/infra/providers), 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.