Untuk ejen AI: markdown halaman ini — /docs-content-en/notifications/answer.md indeks dokumentasi — /llms.txt

Artikel dokumentasi kini tersedia dalam bahasa Inggeris.

Answer a notification

POST /v1/notifications/:id/answer

Sends a text reply to a notification on behalf of the token owner. The Bitrix24 module that sent the notification decides how to handle the reply.

Parameters

Parameter Type Required Description
id (path) number yes Notification identifier — the data.notifications[].id field in the notification feed GET /v1/notifications. A positive integer

Request fields (body)

Field Type Required Description
text string yes Reply text. A whitespace-only string and the string "0" are not accepted

Examples

curl — personal key

Terminal
curl -X POST "https://vibecode.bitrix24.com/v1/notifications/38963/answer" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "text": "Got it, thanks" }'

curl — OAuth application

Terminal
curl -X POST "https://vibecode.bitrix24.com/v1/notifications/38963/answer" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "text": "Got it, thanks" }'

JavaScript — personal key

javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/notifications/38963/answer', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ text: 'Got it, thanks' }),
})

const { data } = await res.json()
console.log(data.resultMessage[0])

JavaScript — OAuth application

javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/notifications/38963/answer', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ text: 'Got it, thanks' }),
})

const { data } = await res.json()

Response fields

Field Type Description
success boolean true on success
data.resultMessage string[] Result messages. Bitrix24 writes the text — escape it before rendering it in an interface

Response example

HTTP 200:

JSON
{
  "success": true,
  "data": {
    "resultMessage": ["Your reply has been sent."]
  }
}

Error response example

422 — the token owner has no notification with this id:

JSON
{
  "success": false,
  "error": {
    "code": "BITRIX_ERROR",
    "message": "Notification is absent, unavailable to the token owner, or cannot perform this action.",
    "b24Code": "NOTIFICATION_ACTION_FAILED"
  }
}

Errors

HTTP Code Description
400 INVALID_PARAMS The path id is not a positive integer
400 INVALID_PARAMS text is missing, is not a string, is whitespace-only or equals "0"
400 INVALID_PARAMS Another body field or a query string parameter was passed, or the body is not a JSON object. The field is named in the message. Checked before the Bitrix24 call
400 FST_ERR_CTP_EMPTY_JSON_BODY The Content-Type: application/json header was sent with an empty body
422 BITRIX_ERROR The notification does not exist, is unavailable to the token owner or does not accept a reply. The Bitrix24 error code NOTIFICATION_ACTION_FAILED is in the error.b24Code field
502 BITRIX_UNAVAILABLE Bitrix24 returned a response without the list of result messages
403 SCOPE_DENIED The key lacks the im scope
403 WRITE_BLOCKED_READONLY_KEY The key is in read-only mode. Checked before the Bitrix24 call
403 BITRIX_ACCESS_DENIED Bitrix24 denied access
401 TOKEN_MISSING The key has no configured tokens
401 MISSING_API_KEY The X-Api-Key header was not sent

Full list of common API errors — Errors.

Known specifics

  • A reply is also accepted for a notification that has no reply field, for example one sent with POST /v1/notifications. The message in data.resultMessage confirms only that Bitrix24 accepted the reply, not that the source module processed it.
  • A repeated reply to the same notification also returns 200. After a reply the notification stays in the feed and is not marked as read — use Mark as read for that.
  • The reply is sent on behalf of the token owner: with a personal key, the key owner; with an OAuth application key and the Authorization: Bearer header, the session user.

See also