Помощен център
Chat API

Уебхукове (Webhooks)

Последна актуализация:

Общ преглед на Webhooks

Webhooks позволяват на ChatLab да уведомява Вашите системи в момента, в който нещо се случи във Вашите чатботове. Вместо да правите периодични заявки (polling) към Management API или да експортирате данни ръчно, Вие регистрирате HTTPS крайна точка (endpoint) и ChatLab изпраща подписана HTTP POST заявка към нея в реално време - когато посетител остави лийд, изпрати контактна форма, оцени разговор, поиска връзка с човек или когато се изпълни AI действие.

Типични приложения:

  • изпращане на нови лийдове директно във Вашата CRM система в секундата, в която са събрани
  • известяване на Вашия екип в Slack, когато посетител поиска live chat (чат на живо)
  • подаване на оценки и обобщения на разговори към Вашите собствени аналитични инструменти
  • наблюдение на изпълнението на AI action (AI действия) и сигнализиране при грешки

Наличност: webhooks са достъпни от план Standard нагоре (функция: Webhooks).

Къде се конфигурират: в администраторския панел отворете Account settings -> Webhooks (Настройки на акаунта -> Webhooks; точно до секцията за Management API). Webhooks работят на ниво акаунт - една крайна точка може да получава събития от всички Ваши ботове или от филтриран набор от тях.

Настройване на крайна точка (endpoint)

  1. Отворете Account settings -> Webhooks и кликнете върху Create endpoint (Създаване на крайна точка).
  2. Попълнете формата за крайна точка:
    • Name (Име) - етикет за Ваша собствена справка, напр. "CRM sync" или "Slack alerts".
    • URL - HTTPS адресът, към който ChatLab ще изпраща събитията чрез POST заявка.
    • Events (Събития) - изберете кои типове събития да получава тази крайна точка (вижте каталога по-долу). Избирайте само това, което Ви е необходимо; събития с голям обем като ai_action.executed могат да генерират сериозен трафик.
    • Bot filter (по избор) (Филтър по ботове) - ограничаване на крайната точка до определени ботове. Оставете празно, за да получавате събития от всички ботове във Вашия акаунт.
    • Custom form filter (по избор) (Филтър по персонализирана форма) - насочва изпратените данни от една конкретна персонализирана форма към тази крайна точка. Настройката филтрира единствено събитието custom_form.submitted; всяко друго събитие, за което сте се абонирали (лийдове, заявки за контакт, разговори, чат на живо, AI действия), се доставя независимо от тази опция.
  3. Потвърдете. Тайната на крайната точка (secret) се показва точно веднъж в диалоговия прозорец за успех - копирайте я веднага и я съхранявайте сигурно. Ще Ви трябва, за да верифицирате подписите (вижте раздела за сигурност по-долу). Текстът в явен вид не може да бъде възстановен по-късно.

Всяка крайна точка разполага и със следните възможности:

  • Превключвател за активиране/деактивиране (Enable/disable toggle) - поставяне на пауза на доставките, без да изтривате крайната точка. Деактивираните крайни точки пропускат събитията тихомълком (те не се нареждат на опашка за по-късно).
  • Send sample event (Изпращане на тестово събитие) - изпраща подписана тестова заявка към Вашия URL адрес, за да можете да тествате приемника си изцяло (end to end). Можете да изберете типа събитие и да редактирате примерните стойности преди изпращане, така че Вашият обработчик да получи реалистични данни. Тестът пристига като редовна доставка с eventType, съответстващ на Вашия избор (или като webhook.test за обикновена проверка на свързаността).
  • Roll secret (Прегенериране на тайна) - генерира нова тайна и анулира старата. Използвайте това, ако има вероятност тайната да е изтекла. Новата тайна отново се показва само веднъж. Актуализирайте Вашия приемник, преди да прегенерирате тайната, в противен случай доставките ще спрат да преминават верификацията на подписа от Ваша страна.
  • Delivery log (Дневник на доставките) - списък за конкретната крайна точка с последните доставки, съдържащ времева марка, тип събитие, HTTP статус, върнат от Вашия сървър, и време за отговор. Неуспешните доставки и паузите от прекъсвача на веригата (circuit breaker) се виждат тук. Дневникът се пази в продължение на 14 дни.

Обвивка на събитието (Event envelope)

Всяка доставка представлява HTTP POST заявка с Content-Type: application/json. Тялото винаги съдържа една и съща обвивка; обектът data е специфичен за съответния тип събитие:

{
  "eventId": "9f1c1c8e-6a2b-4b9e-9d2f-3f8a1e2b4c5d",
  "eventType": "lead.created",
  "timestamp": "2026-08-13T14:22:31Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": { }
}
  • eventId - уникален за всяко събитие. Използвайте го за дедупликация, ако обработката Ви трябва да бъде идемпотентна.
  • eventType - един от описаните по-долу типове; изпраща се също и в заглавката X-ChatLab-Event.
  • timestamp - ISO 8601 UTC време, в което е възникнало събитието.
  • botId / botName - ботът, към който принадлежи събитието.
  • conversationId / sessionId - контекстът на разговора, когато е приложимо.

Каталог на събитията

lead.created

Задейства се, когато посетител изпрати своите координати за контакт - чрез формата за събиране на лийдове, предварителната форма за чат на живо или персонализирана форма, използвана за събиране на лийдове.

{
  "eventId": "9f1c1c8e-6a2b-4b9e-9d2f-3f8a1e2b4c5d",
  "eventType": "lead.created",
  "timestamp": "2026-08-13T14:22:31Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "email": "jane.doe@example.com",
    "name": "Jane Doe",
    "phone": "+1 555 0123",
    "source": "LEAD_COLLECTION_FORM",
    "formCodeName": "lead_form",
    "formName": "Lead form",
    "fields": [
      {"name": "email", "value": "jane.doe@example.com", "type": "email"},
      {"name": "company", "value": "Acme Inc.", "type": "text"},
      {"name": "topics", "value": ["Billing", "Delivery"], "type": "multichoice"},
      {"name": "attachment", "value": "https://api.chatlab.com/aichat/customform/download?key=...&token=...", "type": "file"}
    ],
    "pageUrl": "https://acme.com/pricing"
  }
}
  • source - начинът, по който са събрани данните за контакт: LEAD_COLLECTION_FORM (форма за събиране на лийдове), LIVE_CHAT_FORM (предварителна форма за чат на живо), CONVERSATION (изкуственият интелект е прихванал данните по време на чата), ADMIN_DATA_UPDATE или UPDATE_CLIENT_CONTEXT (редактирани от страна на ChatLab). Изпращанията през формата за връзка с оператор никога не задействат това събитие - вместо него те задействат contact_form.submitted.
  • email, name, phone - координатите за контакт, съпоставени в записа за лийда.
  • Когато за събиране на лийдове се използва персонализирана форма, всяко дефинирано в нея поле се включва в fields, по реда от формата, а formCodeName / formName идентифицират самата форма. При класическата форма за лийдове и двете са null, а fields е празен масив.
  • Всеки запис в fields има структура {name, value, type}. name е техническото наименование на полето, което остава непроменено при редакции на етикетите - използвайте го за съпоставяне (mapping) към Вашата CRM система.
  • За полета от тип multichoice стойността value представлява масив от избраните опции. Полетата за отметка (checkbox) са отделни записи със стойности "true" / "false".
  • За полета от тип file стойността value е връзка за изтегляне на качения файл; webhook известието никога не пренася самото съдържание на файла.
  • pageUrl - страницата, на която се е намирал посетителят в момента на изпращането.

contact_form.submitted

Задейства се, когато посетител изпрати формата за контакт за връзка с човек или персонализирана форма, използвана за свързване с оператор.

{
  "eventId": "3a7b9c2d-1e4f-4a6b-8c0d-5e2f7a9b1c3d",
  "eventType": "contact_form.submitted",
  "timestamp": "2026-08-13T14:25:02Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "email": "jane.doe@example.com",
    "message": "I need help with my last invoice.",
    "source": "CUSTOM_FORM",
    "formCodeName": "contact_form",
    "formName": "Contact form",
    "fields": [
      {"name": "email", "value": "jane.doe@example.com", "type": "email"},
      {"name": "order_number", "value": "A-10293", "type": "text"},
      {"name": "message", "value": "I need help with my last invoice.", "type": "textarea"}
    ]
  }
}
  • email - адресът, оставен от посетителя, на който Вашият екип за поддръжка трябва да отговори.
  • source - CUSTOM_FORM, когато зад контактната форма стои персонализирана форма, или CONTACT_FORM при вградената форма.
  • formCodeName / formName - идентифицират персонализираната форма зад заявката; и двете са null при вградената форма.
  • Когато се използва персонализирана форма, всяко дефинирано в нея поле се включва в fields (в същия формат {name, value, type}, както при lead.created). При вградената контактна форма се попълват само email и message, fields е празен масив, а идентификаторите на формата са null.
  • message - съпоставеното поле за съобщение или всички попълнени стойности, обединени заедно, ако във формата не е дефинирано изрично поле за съобщение.

custom_form.submitted

Задейства се при всяко изпращане на персонализирана форма, независимо от нейното предназначение. Имайте предвид, че формите, чието предназначение е събиране на лийдове или връзка с човек, също така задействат своето специализирано събитие lead.created / contact_form.submitted - абонирайте се за едното или другото в зависимост от това дали Ви е необходим общият, или специализираният изглед, и извършвайте дедупликация по conversationId + timestamp, ако сте абонирани и за двете.

{
  "eventId": "6c1d8e3f-2a5b-4c7d-9e0f-1a4b6c8d0e2f",
  "eventType": "custom_form.submitted",
  "timestamp": "2026-08-13T14:27:45Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "formCodeName": "warranty_claim",
    "formName": "Warranty claim",
    "fields": [
      {"name": "order_number", "value": "A-10293", "type": "text"},
      {"name": "issue", "value": "Damaged on arrival", "type": "textarea"},
      {"name": "photo", "value": "https://api.chatlab.com/aichat/customform/download?key=...&token=...", "type": "file"}
    ],
    "purpose": "STANDALONE"
  }
}
  • formCodeName - постоянното системно име на формата, което остава непроменено при преименуване; използвайте го за маршрутизиране на получените данни във Вашата система. formName е видимият етикет, показван на посетителите.
  • fields използва същата структура от записи {name, value, type} като при lead.created: стойностите за множествен избор са масиви, а стойностите за файлове са връзки за изтегляне.
  • purpose - STANDALONE, LEAD_COLLECTION или HUMAN_CONTACT, в зависимост от това как формата е свързана с чатбота.

conversation.started

Задейства се, когато посетител изпрати първото съобщение в нов разговор.

{
  "eventId": "8e2f0a4b-3c6d-4e8f-a1b2-2c5d7e9f1a3b",
  "eventType": "conversation.started",
  "timestamp": "2026-08-13T14:20:11Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "firstMessage": "Do you ship to Canada?",
    "chatSource": "WIDGET",
    "byAdmin": false,
    "countryCode": "PL",
    "ipAddress": "83.12.44.7"
  }
}
  • firstMessage - точният текст на първото съобщение от посетителя. null, ако разговорът е започнат без текстово съдържание.
  • chatSource - каналът, през който е постъпил разговорът: WIDGET, WHATSAPP, MESSENGER, VOICE, VOICE_PHONE, API, BOOKING, AIRBNB или IDOBOOKING.
  • byAdmin - true, когато разговорът идва от предварителния преглед на чатбота в администраторския панел на ChatLab, а не от реален посетител. Използвайте това, за да не допускате Вашите собствени тестови чатове в CRM системата си.
  • countryCode - двубуквен код на държавата по ISO, определен според IP адреса на посетителя; null, ако не е могъл да бъде установен.
  • ipAddress - IP адресът на посетителя, отчетен от ChatLab; null, когато липсва. Третирайте го като лични данни според GDPR и го съхранявайте само ако разполагате със законово основание.

conversation.rated

Задейства се, когато посетител оцени отговор на бота с палец нагоре или надолу (вижте Оценка на разговори).

{
  "eventId": "1b4c6d8e-5f0a-4b2c-8d3e-4f7a9b1c3d5e",
  "eventType": "conversation.rated",
  "timestamp": "2026-08-13T14:31:09Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "rating": "POSITIVE"
  }
}
  • rating - POSITIVE или NEGATIVE. Премахването на дадена оценка не задейства събитието, така че никога не получавате неутрална стойност.

conversation.summarized

Задейства се, когато ChatLab генерира обобщение на приключил разговор.

{
  "eventId": "4d7e9f1a-6b2c-4d4e-9f0a-5b8c0d2e4f6a",
  "eventType": "conversation.summarized",
  "timestamp": "2026-08-13T14:45:00Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "summary": "Visitor asked about shipping to Canada and delivery times. The bot confirmed availability and quoted 5-7 business days. Visitor left satisfied.",
    "language": "en"
  }
}
  • summary - генерираният текст на обобщението. Обобщенията се създават няколко минути след като разговорът стане неактивен, така че това събитие пристига по-късно от останалите събития за разговора.
  • language - ISO код на езика, на който е написано обобщението, съобразно езика на самия разговор.

client.summarized

Задейства се, когато ChatLab опресни AI профила на даден клиент. Профилът се изгражда наново на базата на предишния профил плюс обобщението на току-що приключилия разговор, поради което това събитие следва conversation.summarized за същия разговор. Клиентите се идентифицират по имейл адрес, поради което той е изведен на най-горно ниво в data.

{
  "eventId": "b5d8f1a3-7c2e-4d9b-a6f0-1e3c5a7b9d2f",
  "eventType": "client.summarized",
  "timestamp": "2026-08-18T09:12:04Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "clientEmail": "jane.doe@example.com",
    "client": {
      "email": "jane.doe@example.com",
      "name": "Jane Doe",
      "phone": "+1 555 0123",
      "countryCode": "PL",
      "ipAddress": "83.12.44.7"
    },
    "clientSummary": "Returning customer interested in international shipping. Asked about delivery times to Canada twice and about return costs once."
  }
}
  • clientEmail - идентификаторът за съпоставяне на клиента с Вашата собствена CRM система. Стойността е null при анонимни посетители, които никога не са оставяли адрес, но събитието въпреки това се изпраща и за тях - прескачайте тези доставки, ако интеграцията Ви разчита на имейл адрес.
  • client - записът за контакт, с който ChatLab разполага за това лице: email, name, phone, countryCode и ipAddress. Всички ключове винаги присъстват; неизвестните стойности са null.
  • clientSummary - пълният текст на профила като чист текст, а не като разлика (diff). Той заменя изцяло предходното обобщение, затова го съхранявайте чрез презаписване, а не с добавяне.
  • Профилът се изгражда наново само за ботове с включена памет за чатове и само за разговори, които са били неактивни достатъчно дълго, за да бъдат обобщени - очаквайте това събитие няколко минути след края на разговора, а не веднага.

live_chat.requested

Задейства се, когато изкуственият интелект прехвърли разговора към Live Chat (чат на живо), било защото посетителят е поискал връзка с човек, било защото ботът е преценил, че е необходим оператор.

{
  "eventId": "7a0b2c4d-8e3f-4a5b-b0c1-6d9e1f3a5b7c",
  "eventType": "live_chat.requested",
  "timestamp": "2026-08-13T14:33:20Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "requestedBy": "AI"
  }
}
  • requestedBy - в момента стойността винаги е AI, тъй като прехвърлянето винаги се инициира от действието за чат на живо на бота, включително когато посетителят го поиска с думи в свободен текст. Третирайте полето като отворен списък от стойности (enum): обработвайте непознати стойности, вместо да разчитате единствено на AI.
  • Събитието показва, че е поискано прехвърляне, а не че оператор го е поел. За тази цел изчакайте събитието live_chat.started.

live_chat.started

Задейства се, когато оператор се присъедини и сесията за чат на живо действително започне.

{
  "eventId": "0c3d5e7f-9a4b-4c6d-a1b2-7e0f2a4b6c8d",
  "eventType": "live_chat.started",
  "timestamp": "2026-08-13T14:33:55Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {}
}
  • Обектът data умишлено е празен. Всичко необходимо се намира в обвивката (envelope): botId идентифицира чатбота, а conversationId / sessionId свързват събитието с разговора, за който вече сте получили live_chat.requested.

live_chat.ended

Задейства се, когато сесията за чат на живо приключи.

{
  "eventId": "2e5f7a9b-0c5d-4e7f-b2c3-8f1a3b5c7d9e",
  "eventType": "live_chat.ended",
  "timestamp": "2026-08-13T14:52:41Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "durationSeconds": 1126
  }
}
  • durationSeconds - колко време операторът е участвал в разговора, изчислено от момента на стартиране на сесията. Полето се пропуска в редките случаи, когато сесията приключи, без изобщо да е била стартирана.

ai_action.executed

Задейства се всеки път, когато ботът изпълни AI action - управлявано извикване на интеграция или персонализирана API функция. Това е събитие с голям обем: активен бот за електронна търговия може да изпълнява стотици действия дневно, а една-единствена реплика на посетител може да предизвика няколко. Абонирайте се за него чрез отделна крайна точка или се уверете, че Вашият приемник може да поеме обема.

{
  "eventId": "5f8a0b2c-1d6e-4f8a-c3d4-9a2b4c6d8e0f",
  "eventType": "ai_action.executed",
  "timestamp": "2026-08-13T14:21:03Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "actionName": "search_products",
    "status": "SUCCESS",
    "durationMs": 842,
    "errorMessage": null
  }
}
  • actionName - името на изпълненото действие така, както го вижда изкуственият интелект, например search_products при управлявана интеграция или името, което сте задали за персонализирано API действие.
  • status - SUCCESS или ERROR.
  • durationMs - продължителността на изпълнение на действието в милисекунди. Полезно за откриване на бавна интеграция, преди посетителите да започнат да се оплакват от нея.
  • errorMessage - причината за неуспеха; попълва се само когато status е ERROR; в противен случай е null.

webhook.test

Изпраща се от бутона Send sample event, когато изпълнявате обикновена проверка на свързаността. Подписва се по абсолютно същия начин, както реално събитие.

{
  "eventId": "9b2c4d6e-3f8a-4b0c-d5e6-0b3c5d7e9f1a",
  "eventType": "webhook.test",
  "timestamp": "2026-08-13T14:10:00Z",
  "botId": 1234,
  "botName": "Support Bot",
  "conversationId": "conv_a1b2c3",
  "sessionId": "sess_x9y8z7",
  "data": {
    "message": "Test delivery from ChatLab"
  }
}
  • message - фиксиран текст, който винаги е един и същ. Полетата в обвивката съдържат примерни стойности, затова никога не третирайте доставка от тип webhook.test като реални данни.
  • Това е единственият тип събитие, за който не можете да се абонирате в настройките на крайна точка: то се изпраща при поискване от администраторския панел и винаги достига до крайната точка, върху която сте кликнали, независимо кои събития слуша тя.

Сигурност: верифициране на доставките

Всяка доставка съдържа четири хедъра:

Header Value
X-ChatLab-Signature sha256=<hex hmac> - HMAC-SHA256 подпис на съдържанието (payload)
X-ChatLab-Timestamp Unix време в секунди към момента, в който доставката е била подписана
X-ChatLab-Event Типът на събитието, напр. lead.created
X-ChatLab-Delivery Уникален идентификатор на доставката, съвпадащ с eventId на тялото

Подписът се изчислява като HMAC-SHA256 върху низа {timestamp}.{rawBody}, използвайки вашия таен ключ за крайната точка (endpoint secret), където {timestamp} е стойността на X-ChatLab-Timestamp, а {rawBody} е суровото, непарсирано тяло на заявката. Винаги проверявайте спрямо суровите байтове - повторното сериализиране на парсиран JSON ще промени последователността от байтове и ще наруши валидността на подписа.

За защита срещу атаки с повторение (replay attacks), отхвърляйте доставки, чийто X-ChatLab-Timestamp е по-стар от 5 минути.

Node.js

const crypto = require('crypto');

function verifyChatLabSignature(req, secret) {
    const signature = req.headers['x-chatlab-signature'];
    const timestamp = req.headers['x-chatlab-timestamp'];
    if (!signature || !timestamp) return false;

    // Reject stale deliveries (older than 5 minutes)
    const ageSeconds = Math.abs(Date.now() / 1000 - Number(timestamp));
    if (ageSeconds > 300) return false;

    // rawBody must be the raw request body bytes, not re-serialized JSON.
    // With Express: app.use(express.json({ verify: (req, res, buf) => { req.rawBody = buf; } }))
    const expected = 'sha256=' + crypto
        .createHmac('sha256', secret)
        .update(timestamp + '.' + req.rawBody)
        .digest('hex');

    const a = Buffer.from(signature);
    const b = Buffer.from(expected);
    return a.length === b.length && crypto.timingSafeEqual(a, b);
}

PHP

<?php
function verifyChatLabSignature(string $secret): bool
{
    $signature = $_SERVER['HTTP_X_CHATLAB_SIGNATURE'] ?? '';
    $timestamp = $_SERVER['HTTP_X_CHATLAB_TIMESTAMP'] ?? '';
    if ($signature === '' || $timestamp === '') {
        return false;
    }

    // Reject stale deliveries (older than 5 minutes)
    if (abs(time() - (int) $timestamp) > 300) {
        return false;
    }

    $rawBody = file_get_contents('php://input');
    $expected = 'sha256=' . hash_hmac('sha256', $timestamp . '.' . $rawBody, $secret);

    return hash_equals($expected, $signature);
}

Ако верификацията е неуспешна, отговорете с 401 и отхвърлете данните. Никога не обработвайте неверифицирани доставки - всеки, който открие вашия URL адрес, може да изпрати произволен JSON чрез POST заявка към него.

Поведение при доставка

Запознайте се с тези гаранции, преди да разработвате решения с уебхукове:

  • Отговаряйте бързо. Вашата крайна точка трябва да отговори в рамките на 3 секунди, в противен случай доставката се счита за неуспешна. Върнете отговор 2xx незабавно и обработвайте данните асинхронно (поставете ги в опашка, след което потвърдете приемането) - не правете извиквания към CRM или записи в базата данни преди да изпратите отговор.
  • Fire-and-forget, най-много веднъж (at-most-once). Всяко събитие получава точно един опит за доставка - няма повторни опити. Ако вашата крайна точка не работи, изтече времето за изчакване (timeout) или върне статус, различен от 2xx, това събитие се губи и няма да бъде доставено повторно. Уебхуковете са известия, а не репликирано хранилище на данни: когато имате нужда от гарантирана пълнота, сверявайте данните чрез Management API или вашите експорти на лийдове.
  • Прекъсвач (Circuit breaker). След 5 последователни неуспешни доставки за даден бот, доставките за този бот се спират на пауза за 5 минути. Събитията, възникнали по време на паузата, се отхвърлят, а дневникът на доставките показва записи CIRCUIT_OPEN, за да виждате точно кога и защо трафикът е бил ограничен. Доставките, пропуснати от активиран прекъсвач, не се зачитат за автоматично деактивиране.
  • Автоматично деактивиране. Проверката се извършва в момента на неуспешна доставка, а не по таймер. Ако дадена доставка е неуспешна и няма нито една успешна доставка в продължение на 7 дни - изчислено от последния успех или от датата на създаване на крайната точка, ако тя никога не е имала успешен опит - крайната точка се деактивира и Вие получавате имейл известие. Всеки единичен статус 2xx в произволен момент нулира този брояч. Крайна точка, която не получава трафик, никога не се деактивира, тъй като при нея няма неуспешни опити. Активирайте я отново от Account settings (Настройки на акаунта), след като поправите вашия приемник; броячът на грешките и маркерът за автоматично деактивиране се изчистват при повторното включване, а събитията, пропуснати по време на деактивацията, не се наваксват.
  • 410 Gone. Ако вашата крайна точка отговори с HTTP статус 410 Gone, ChatLab я деактивира незабавно. Използвайте това за програмно извеждане от експлоатация на крайна точка директно от приемащата страна.
  • Идемпотентност. При нормална работа не се очакват дублиращи се доставки, но ако вашата обработка изисква строга идемпотентност, премахвайте дубликатите според eventId (наличен и в хедъра X-ChatLab-Delivery).

Ограничения

  • До 10 крайни точки за уебхукове на акаунт.
  • Съхранение на дневника за доставки: 14 дни. По-старите записи се изтриват автоматично.

Свързани статии

  • Lead collection (Събиране на лийдове) - формулярът зад lead.created
  • Human Support Contact form (Формуляр за връзка с човешка поддръжка) - формулярът зад contact_form.submitted
  • Live Chat - работният процес зад събитията live_chat.*
  • Conversation rating (Оценка на разговор) - оценяването с палец нагоре/надолу зад conversation.rated
  • AI Actions (Действия на AI) - интеграциите зад ai_action.executed
  • Chat API - извиквания за обратна връзка (callbacks) от уиджета в браузъра (клиентски еквивалент на уебхуковете)
  • Management API - REST API за управление на ботове и данни за потреблението
Търсене във всички статииПопитайте асистента