Activate the Marketplace trial

POST /v1/portals/:id/activate-market-trial

Activates the one-time Bitrix24 Marketplace trial for the Bitrix24 account the calling key is bound to. The result is the same as starting the trial in the Vibecode dashboard, but without a browser. Availability depends on the account region: an account in an international region cannot activate the trial — the call is refused and nothing changes.

Parameters

No request body is required, so send the request without a Content-Type header. A client that sets Content-Type: application/json on every request must send the body {} — a request with that header and an empty body is rejected before the call is processed.

Examples

curl — personal key

curl -X POST \
  -H "X-Api-Key: YOUR_API_KEY" \
  https://vibecode.bitrix24.com/v1/portals/YOUR_PORTAL_ID/activate-market-trial

curl — OAuth application

curl -X POST \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  https://vibecode.bitrix24.com/v1/portals/YOUR_PORTAL_ID/activate-market-trial

JavaScript — personal key

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/portals/${portalId}/activate-market-trial`,
  {
    method: 'POST',
    headers: { 'X-Api-Key': 'YOUR_API_KEY' },
  },
)

const { success, data } = await res.json()
if (success) {
  // activated — activated by this call, already_active — access existed before the call
  console.log(data.status, data.trialEndsAt)
}

JavaScript — OAuth application

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/portals/${portalId}/activate-market-trial`,
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
    },
  },
)

const { success, data } = await res.json()

Response fields

Response example

The trial was activated by this call:

{
  "success": true,
  "data": {
    "status": "activated",
    "trialEndsAt": "2026-08-01T00:00:00.000Z"
  }
}

The account already had access — the response carries no trialEndsAt field:

{
  "success": true,
  "data": {
    "status": "already_active"
  }
}

Error response example

403 — the identifier in the path belongs to another account:

{
  "success": false,
  "error": {
    "code": "PORTAL_MISMATCH",
    "message": "This key is not authorized for the requested portal"
  }
}

Errors

The full list of common API errors — Errors.

Known specifics

The GET /v1/me response carries no account identifier. It returns only the domain. A personal key takes the identifier from the portalId field of the records returned by GET /v1/apps — this works when the account has at least one app. The other sources are the GET /v1/portals response for a management key or the Vibecode dashboard. Without the identifier the call runs into 403 PORTAL_MISMATCH.

A repeat call after a successful activation changes nothing. An account whose trial was already activated through Vibecode gets 409 ALREADY_ACTIVATED — the platform remembers the activation and does not call Bitrix24 a second time.

A 200 response does not mean the call changed anything. An account that already has access gets 200 with status already_active instead of a refusal. Distinguish "activated now" from "access already existed" by the data.status field, not by the response code.

The response does not disclose the reason for unavailability. The code 409 TRIAL_ACTIVATION_UNAVAILABLE is returned for every condition with the same wording. The main ones are: the account is self-hosted, the account region is not eligible for the Marketplace trial, the trial on the Bitrix24 side is already used up, and the account has no developer key. An account in an international region is never eligible, so every call for such an account ends in this code. The list is not limited to those: the same code is also returned for a platform-side failure that only support can clear. So a refusal that contradicts the state of the account is worth forwarding to support rather than treating as final.

The rate limit is counted per account and is consumed by refusals as well. The cap is three requests per hour, and the check runs before the other conditions, so a failed attempt — with another account's identifier or with a read-only key — reduces the remaining quota just as a successful one does. The remaining quota and the reset time are returned in the X-RateLimit-Remaining and X-RateLimit-Reset headers.

See also

• Management keys
• List of apps
• Keys and authorization
• Access mode
• Create an application
• Errors