Re-subscribe to events

POST /v1/bots/:botId/resubscribe

Restores the bot's subscription to Bitrix24 events. Use it when the bot is active but GET /v1/bots/:botId/events has stopped returning events. No request body is required.

Parameters

Examples

curl — personal key

curl -X POST https://vibecode.bitrix24.com/v1/bots/42/resubscribe \
  -H "X-Api-Key: YOUR_API_KEY"

curl — OAuth application

curl -X POST https://vibecode.bitrix24.com/v1/bots/42/resubscribe \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN"

JavaScript — personal key

const res = await fetch('https://vibecode.bitrix24.com/v1/bots/42/resubscribe', {
  method: 'POST',
  headers: { 'X-Api-Key': 'YOUR_API_KEY' },
})
const { data } = await res.json()
console.log(data) // { resubscribed: true, eventMode: 'fetch' }

JavaScript — OAuth application

const res = await fetch('https://vibecode.bitrix24.com/v1/bots/42/resubscribe', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
  },
})

Response fields

Response example

{
  "success": true,
  "data": {
    "resubscribed": true,
    "eventMode": "fetch"
  }
}

Error response example

404 — bot not found:

{
  "success": false,
  "error": {
    "code": "BOT_NOT_FOUND",
    "message": "Bot 42 not found. Register it first via POST /v1/bots."
  }
}

Errors

Full list of common API errors — Errors.

Known specifics

When to use. The bot is registered and active — messages arrive in chats and the bot appears in the GET /v1/bots list — but the event queue stays empty. A hint field in the GET /v1/bots/:botId/events response confirms the diagnosis, but its absence does not make the call unnecessary: the hint only shows up once the queue has stayed persistently empty. Re-subscription restores delivery and preserves the Open Channels and welcome-bot bindings, unlike re-registration via POST /v1/bots.

Repeated calls are safe. Each request re-sends the bot's delivery mode to Bitrix24, so re-subscription can be called several times in a row.

Bitrix24 account address change. If a successful response contains needsReregistration: true, the platform recorded an address change, while resubscribed: true only means the call completed; it did not restore delivery. For a standalone Bot, delete the old registration through DELETE /v1/bots/:botId before reusing the same code, or register a new unique code, then restore the Open Channels and WELCOME_BOT bindings. The same code may reuse the old identity and does not guarantee a new bot ID. For a bot owned by an Agent or Managed Bot, do not call DELETE /v1/bots/:botId: use the owner resource's recovery lifecycle, or contact support if that recovery is unavailable.

An absent needsReregistration field does not rule out an address change that happened before this diagnostic became available. If the address changed and resubscription did not restore delivery, choose the same owner-aware recovery path.

webhook mode. For a bot with eventMode: "webhook", re-subscription also re-sends the stored webhook address.

See also

• Events
• Troubleshooting
• Bot re-authorization