Интеграции и письма

Состояние интеграций и журнал отправок

Права и тариф для всех методов этого раздела: тарифная опция самой интеграции плюс право участника integrations. Право закрывает даже чтение — участник без него не должен видеть, куда уходят ответы. Владелец воркспейса проходит всегда.

Отказы:

47. Состояние интеграций опроса

В API с 08.09.2026

Отвечает на «почему заявки не приходят»: по каждой интеграции сразу видно, подключена ли она, включена ли отправка и разрешает ли её тариф.

GET/quiz/{id}/integrations
Аутентификация: Обязательна

Пример ответа (200)

{
    "status": true,
    "quiz_id": 18547,
    "integrations": {
        "telegram": {"connected": true, "enabled": true, "allowed_by_tariff": true, "blocked": null},
        "max": {"connected": false, "enabled": false, "allowed_by_tariff": true, "blocked": "not_connected"},
        "amocrm": {"connected": true, "enabled": false, "allowed_by_tariff": true, "blocked": "disabled"},
        "bitrix24": {"connected": false, "enabled": false, "allowed_by_tariff": false, "blocked": "blocked_by_tariff"},
        "zapier": {"connected": false, "enabled": false, "allowed_by_tariff": true, "blocked": "not_connected"},
        "google_sheets": {"connected": false, "enabled": false, "allowed_by_tariff": true, "blocked": "not_connected"}
    }
}

blocked — готовая причина, по которой ответы не уходят: blocked_by_tariff, not_connected или disabled. Пусто — отправка работает.

Вебхуки в этот ответ не входят: у них своя настройка и свой журнал доставки.

48. Журнал отправок мессенджера

В API с 08.09.2026

Свой журнал отправок есть у Telegram и MAX. По нему видно причину, по которой сообщение не ушло: бота выгнали из группы, чат удалён, токен отозван.

GET/quiz/{id}/integrations/logs
Аутентификация: Обязательна

Query параметры

Пример ответа (200)

{
    "status": true,
    "quiz_id": 18547,
    "integration": "telegram",
    "total": 143,
    "page": 1,
    "per_page": 20,
    "last_page": 8,
    "unsent_count": 3,
    "counts": { "all": 143, "failed": 3, "queued": 0 },
    "logs": [...]
}

unsent_count — сколько отправок сорвалось и ждёт повтора.

total и last_page считаются с учётом status. counts — по всему журналу, от status и страницы не зависит: all — все записи, failed — не дошли (то же, что unsent_count), queued — в очереди на отправку; дошедших — all − failed − queued. Поле counts — с 2026-10-13. У каждой записи есть created_at (ISO 8601, UTC) — время попытки: у недошедшей sent_at пустой. У недошедшей записи заполнен хотя бы error_message (у Telegram ещё error_type), при отказе мессенджера — и error_code; у таймаута и обрыва связи error_code — номер ошибки cURL, 28 — таймаут. Старые записи (Telegram — до июня 2026, MAX — до октября 2026) могут быть без причины.

error_type у Telegram: bot_blocked, user_deactivated, chat_not_found, thread_not_found (тема удалена), topic_closed (тема закрыта — её можно открыть снова; с 2026-10-13, раньше записывалось как thread_not_found), no_access, other.

Неподключённая интеграция отвечает 400 с кодом not_connected, а не пустым списком: журнала в этом случае не существует, и пустой список означал бы, что отправок не было.

49. Досылка неотправленного

В API с 08.09.2026

Когда причину отказа устранили — бота вернули в группу, токен перевыпустили, — накопившееся можно дослать: либо одну запись журнала, либо все неудачные за период.

POST/quiz/{id}/integrations/logs/resend
Аутентификация: Обязательна

Тело запроса (JSON)

Без log_id и без периода дошлются все неудачные отправки. log_id вместе с периодом — 422: это разные действия, и вместе они означали бы, что период молча проигнорирован.

Пример ответа (200)

{
    "status": true,
    "quiz_id": 18547,
    "integration": "telegram",
    "resent": 3
}

Отправка ответов в CRM

Молчащая интеграция выглядит одинаково при трёх разных причинах: отправка выключена, тариф её не включает или на стороне CRM отозвали токен. Последнее со стороны опроса не видно вообще — поэтому проверка связи здесь отдельным методом.

{crm} в путях — amocrm или bitrix24. Другое значение — 422 с кодом unknown_crm. Опрос без подключённой CRM — 400 с кодом not_connected: это не пустое состояние, а отсутствие настройки.

Права и тариф — как во всём разделе: тарифная опция этой CRM плюс право участника integrations.

50. Состояние подключения CRM

В API с 08.09.2026

GET/quiz/{id}/integrations/crm/{crm}
Аутентификация: Обязательна

Пример ответа (200)

{
    "status": true,
    "quiz_id": 18547,
    "crm": "bitrix24",
    "connected": true,
    "is_active": false
}

51. Включить или выключить отправку в CRM

В API с 08.09.2026

POST/quiz/{id}/integrations/crm/{crm}/toggle
Аутентификация: Обязательна

Тело запроса (JSON)

Пример ответа (200)

{"status": true, "quiz_id": 18547, "crm": "bitrix24", "is_active": true}

Отказ записи — 400 с кодом toggle_failed.

52. Проверить, живо ли подключение

В API с 08.09.2026

Токен отзывают на стороне CRM, и со стороны опроса это выглядит как молчащая интеграция. Метод обращается к порталу и отвечает, отвечает ли он.

GET/quiz/{id}/integrations/crm/{crm}/check
Аутентификация: Обязательна

Пример ответа (200)

{
    "status": true,
    "quiz_id": 18547,
    "crm": "bitrix24",
    "is_active": true,
    "connection_ok": false
}

Мёртвая связь — это результат проверки, а не сбой вызова, поэтому ответ успешный: смотреть надо на connection_ok.

53. Справочники CRM и текущее сопоставление

В API с 08.09.2026

То же, что видит человек в форме настройки: поля лида, сделки, контакта и компании, воронки со стадиями, ответственные. Рядом — сопоставление, сохранённое у опроса сейчас.

GET/quiz/{id}/integrations/crm/{crm}/fields
Аутентификация: Обязательна

Query параметры

Пример ответа (200)

{
    "status": true,
    "quiz_id": 18547,
    "crm": "bitrix24",
    "is_active": true,
    "sections": ["lead", "pipelines"],
    "directories": {
        "lead": {...},
        "deal_categories": [...],
        "deal_stages": [...]
    },
    "current_mapping": {"lead": {"enabled": true, "fields": {...}}}
}

Различия CRM отдаются как есть, а не подгоняются друг под друга: у amoCRM сделка и есть лид, поэтому разделы deal и types приходят со значением null — это ответ, а не сбой. У Bitrix24 раздел pipelines возвращает два справочника: воронки (deal_categories) и стадии (deal_stages).

Отозванный доступ к порталу — 400 с кодом connection_lost, сбой обращения к справочникам — 400 с кодом directories_failed. Справочники читаются живыми запросами в CRM, поэтому вызов не мгновенный.

Сопоставление полей опроса с полями CRM

Неверная форма сопоставления не вызывает ошибки при сохранении, а молча ломает доставку: заявки начинают приходить пустыми или встают не в ту воронку, и заметить это можно много позже. Поэтому каждое значение проверяется до записи.

Две CRM устроены по-разному, поэтому и методы разные. За один вызов правится одна сущность или один блок: правка одного не сбрасывает остальное, а непереданные ключи остаются прежними.

121. Bitrix24: сопоставление по сущностям

В API с 08.09.2026

POST/quiz/{id}/integrations/bitrix24/mapping/{entity}

{entity} — lead, contact, company, deal; другое значение — 422 с кодом unknown_entity.

Набор полей заменяется целиком, но только когда его передали: вызов без fields оставляет прежний набор. Каждое поле берёт значение откуда-то одного — поле с обоими источниками даёт 422 с кодом field_ambiguous (адаптер в этом случае взял бы вопрос и молча проигнорировал постоянное значение), поле без источников — field_empty.

Стадия принадлежит воронке. У воронки по умолчанию стадия не начинается с «C», у воронки N обязана начинаться с «CN:». Несовместимая — 422 с кодом stage_mismatch; стадия у сущности, кроме сделки — stage_deal_only. Воронка берётся из вызова, а если её не передали — из уже сохранённых настроек.

В ответе есть stage_dropped: сервис молча выбрасывает стадию, которую не принял, и это единственный способ узнать, что она не записалась.

122. amoCRM: сопоставление по блокам

В API с 08.09.2026

POST/quiz/{id}/integrations/amocrm/mapping/{block}

{block} — deal (сделка), list (контакты, компании, каталоги), task (задача); другое значение — 422 с кодом unknown_block.

Каждое значение сверяется с живыми справочниками портала. Отказы приходят кодом: pipeline_unknown (нет такой воронки), status_mismatch (стадия из другой воронки), field_unknown (нет такого поля), bind_not_widget (значение поля берётся из ответа, поэтому здесь нужен вопрос, а не текст), subtype_without_bind, user_unknown, title_empty, directories_unavailable.

Пустой список active означает «не создавать» — это значение, а не отсутствие значения, и оно сохраняется. Ключи, которых нет в этом методе (например значения полей-списков, их заводит кабинет), сохраняются как были.

Без живого подключения к порталу метод отвечает 400 с кодом connection_lost и ничего не записывает: справочников не прочитать, а проверять нечем.

Метод POST /amocrm/quiz/{id}/settings остаётся: им пользуется виджет внутри amoCRM, который сохраняет весь набор настроек целиком. Он тоже проверяет тело по форме и сверяет воронки со справочниками портала, но работает с полным объектом настроек, а не с одним блоком. Для новых интеграций удобнее этот метод — он правит по одному блоку за раз.

Интеграции

AmoCRM: Аккаунт

В API с 19.02.2026

Получает общую информацию об аккаунте AmoCRM: воронки, пользователи, типы задач и дополнительные поля.

GET/amocrm/account
Аутентификация: Обязательна

Отказы

Те же коды и статусы отдаёт GET /amocrm/lists; его собственный код amocrm_catalogs_unavailable остаётся для прочих причин.

Пример ответа (200)

{
    "pipelines": [...],
    "users": [...],
    "task_types": [...],
    "custom_fields": [...]
}

AmoCRM: Списки

В API с 19.02.2026

Получает каталоги (списки) из AmoCRM.

GET/amocrm/lists
Аутентификация: Обязательна

Пример ответа (200)

{
    "response": {
        "items": [...]
    }
}

AmoCRM: Поля каталога

В API с 22.09.2026

Возвращает поля элементов одного каталога amoCRM. У элемента каталога свой набор полей — не такой, как у сделки, контакта или компании, поэтому для сопоставления нужен именно он.

GET/amocrm/catalogs/{id}/fields
Аутентификация: Обязательна

Отказы

Те же, что у GET /amocrm/account; прочие причины — 400 amocrm_catalogs_unavailable.

Пример ответа (200)

{
    "response": {
        "items": [
            {
                "id": 2001,
                "name": "Артикул",
                "type": "text",
                "code": null,
                "sort": 10,
                "is_required": false,
                "enums": []
            }
        ]
    }
}

Поля, значение которых считает сам портал (is_computed) или которые служебные (is_api_only), в ответ не попадают: запись в них amoCRM отклоняет. У полей-списков приходят варианты (enums) — именно их номера портал ждёт при отправке значения.

AmoCRM: Ссылка на повторную авторизацию

В API с 22.09.2026

Возвращает ссылку, по которой пользователь заново подключает amoCRM к своему аккаунту WebAsk. Нужна, когда портал отозвал доступ (401 amocrm_token_revoked у методов выше): переподключиться можно прямо из виджета, не заходя в конструктор. В ссылке уже зашифрована метка пользователя, поэтому новые токены после авторизации сохранятся именно ему.

GET/amocrm/auth-url
Аутентификация: Обязательна

К amoCRM метод не обращается, поэтому отказов портала у него нет. Без авторизации — 401 с кодом user_not_authenticated.

Пример ответа (200)

{
    "status": true,
    "auth_url": "https://www.amocrm.ru/oauth?client_id=...&state=...&mode=post_message"
}

AmoCRM: Привязка доступа из установки виджета

В API с 24.09.2026

Когда виджет ставят в самом amoCRM, портал присылает нам код доступа и адрес аккаунта, но не говорит, чей это пользователь WebAsk. Сервер сразу меняет код на токены:

• если этот аккаунт amoCRM уже подключён у кого-то в WebAsk (переустановка виджета) — токены обновляются у всех таких пользователей, ничего вызывать не нужно;
• если аккаунт новый — токены ждут привязки 30 дней.

Этот метод привязывает ожидающие токены к текущему пользователю. Виджет вызывает его через $authorizedAjax amoCRM: тот добавляет заголовок X-Auth-Token — одноразовый JWT, подписанный секретом нашей интеграции. Адрес аккаунта сервер берёт только из этого токена (поле iss), поэтому забрать доступ чужого аккаунта нельзя.

POST/amocrm/link
Аутентификация: Обязательна (ключ WebAsk) и заголовок X-Auth-Token от amoCRM

Вызывать можно сколько угодно раз. Если ждущих токенов нет, метод ничего не меняет и отвечает, подключён ли этот аккаунт amoCRM у пользователя сейчас.

Пример ответа (200)

{
    "status": true,
    "linked": true
}

AmoCRM: Опросы

В API с 19.02.2026

Возвращает список опросов пользователя с информацией об активности интеграции AmoCRM.

GET/amocrm/quiz
Аутентификация: Обязательна

Query параметры

Аналогичны GET /quiz (sort, order, limit, offset, folder_id).

Пример ответа (200)

[
    {
        "id": 123,
        "name": "Опрос с Amo",
        "amocrm_is_active": true,
        "folder": { ... }
    }
]

AmoCRM: Настройки опроса

В API с 19.02.2026

Получение или сохранение настроек AmoCRM для конкретного опроса.

Получение: GET /amocrm/quiz/{id}/settings
Сохранение: POST /amocrm/quiz/{id}/settings

Тело запроса для сохранения (JSON)

Тело проверяется по форме: значение не того типа даёт 422 с кодом validation_failed и разбором по полям в errors. Разделы, которых нет в наборе check, deal, list, task, extra_fields, отказом не считаются — они молча отбрасываются и в настройки не попадают.

Выбранные воронки и стадии сверяются со справочниками портала — по подключению владельца опроса, тому же, которое потом отправляет ответы. Сверка идёт только когда выбор воронок или стадий изменился: справочники стоят шести запросов к amoCRM, а виджет сохраняет настройки на каждое переключение. Стадии снятых воронок в сверку не попадают — виджет пишет объект целиком и такие ключи в нём остаются.

Если справочники портала не прочитались (подписка не оплачена, amoCRM недоступна), сохранение не блокируется: иначе клиент не смог бы донастроить интеграцию, пока у него проблемы на стороне amoCRM.

Вебхуки опроса

Вебхук уводит ответы в свою систему. Значения заголовков в ответах подменяются на ***: там носят ключи и токены доступа, отдавать их обратно незачем. Имена заголовков видны — по ним понятно, что настроено.

Тариф проверяется на записи: настраивать отправку, которой тариф не даст сработать, смысла нет. Выключить вебхук можно на любом тарифе — запрет касается настройки, а не отказа от неё.

54. Список вебхуков

В API с 08.09.2026

GET/quiz/{id}/webhooks

{
    "status": true,
    "quiz_id": 18547,
    "is_active": true,
    "items": [{"id": 50, "title": "Наша CRM", "url": "https://example.com/hook",
               "method": "post", "is_active": true, "incomplete": false, "hours": 0,
               "headers": [{"name": "Authorization", "value": "***"}]}]
}

55. Создать вебхук

В API с 08.09.2026

POST/quiz/{id}/webhooks

В ответе — webhook_id нового вебхука и полный список items.

Повторный вызов с тем же url и method вебхук не задваивает: приходит 400 с кодом webhook_exists и webhook_id уже существующего. Иначе приёмник начал бы получать по два запроса на каждый ответ.

56. Изменить вебхук

В API с 08.09.2026

POST/quiz/{id}/webhooks/{webhookId}

Поля те же, все необязательные: непереданное остаётся прежним. Заголовки при этом сохраняются, хотя запись перезаписывает вебхук целиком — прежнее состояние подмешивается на нашей стороне. Передали headers — они заменяют прежний список полностью.

Неизвестный вебхук — 400 с кодом webhook_not_found.

57. Удалить вебхук

В API с 08.09.2026

DELETE/quiz/{id}/webhooks/{webhookId}

58. Включить или выключить вебхук

В API с 08.09.2026

POST/quiz/{id}/webhooks/{webhookId}/toggle

59. Журнал доставки вебхука

В API с 08.09.2026

GET/quiz/{id}/webhooks/{webhookId}/logs

В ответе total, page, per_page, last_page (с учётом status), counts и logs. counts — { "all": 200, "failed": 71, "queued": 0 } по всему журналу эндпоинта, от status и страницы не зависит. У каждой записи logs на верхнем уровне answer_id — какой ответ ушёл, null у тестового запроса. Поля counts и answer_id — с 2026-10-13. Причина отказа — detail.error_code (timeout, dns_failed, ssl_error, connection_failed, too_many_redirects, unsafe_url, http_error, unknown) и/или detail.http_code с response_body.

Значения заголовков в записях журнала подменяются на ***, как и в списке вебхуков: журнал хранит те же ключи доступа к приёмнику, которыми пользуется досылка. Имена заголовков видны.

60. Досылка вебхука

В API с 08.09.2026

POST/quiz/{id}/webhooks/{webhookId}/logs/resend

log_id вместе с периодом — 422.

Повтор уходит с текущими заголовками вебхука и телом, собранным заново по текущему набору полей и их именам (данные ответа — из снимка исходной отправки). Если ответ удалён, тело — сохранённое в журнале, заголовки всё равно текущие. В журнал записывается то, что ушло при повторе. Тело запроса вебхука, включая поля answer_id и is_complete, описано в разделе Webhooks.

Уведомления в Telegram и MAX

Тарифная опция мессенджера (telegram, max) плюс право integrations.

101. Мессенджер опроса

В API с 08.09.2026

{messenger} — telegram или max; другое значение даёт 422 с кодом unknown_messenger.

{
    "status": true, "quiz_id": 18547, "messenger": "telegram", "is_active": true,
    "subject": "Новая заявка", "buttons_enabled": true,
    "bot_url": "https://t.me/webask_bot?start=1f0c...",
    "recipients": [{"id": 123456789, "title": "Отдел продаж"}],
    "hidden_widget_ids": ["b3f1c2d4-..."]
}

Подключение делает человек. activate заводит интеграцию и выдаёт bot_url — по этой ссылке бота добавляют в чат или группу; пока этого не сделали, отправлять некуда. Получатели появляются сами, когда бота добавили.

Список исключённых вопросов задаётся целиком: чего в нём нет, то в сообщение вернётся. Непереданный список не трогается — иначе правка одной темы сняла бы все исключения, и вопросы с персональными данными снова ушли бы в чат.

test отправляет пробное сообщение всем подключённым получателям. Выключенная интеграция — 400 с кодом inactive, интеграция без получателей — 400 с кодом no_recipients, сбой отправки — 400 с кодом test_failed.

Опрос без подключённого мессенджера — 400 с кодом not_connected для всего, кроме activate.

Google Таблицы

Подключение остаётся в кабинете: там вход в аккаунт Google и выбор файла на Диске. Тарифная опция googleSheets плюс право integrations.

102. Выгрузка ответов в таблицу

В API с 08.09.2026

{
    "status": true, "quiz_id": 18547, "is_active": true,
    "table_title": "Ответы опроса", "table_url": "https://docs.google.com/...",
    "access": "ok", "requires_reconnect": false,
    "enable_timestamp": true, "enable_personal_data": false,
    "sync_mode": "scheduled", "schedule_hour": 9, "schedule_minute": 30,
    "last_synced_at": "2026-09-09 09:30:12", "hidden_widget_ids": []
}

access — состояние доступа к таблице. Чаще всего выгрузка замолкает именно из-за отозванного на стороне Google доступа, и тогда приходит requires_reconnect: true: переподключение делают в кабинете.

Список исключённых вопросов задаётся целиком, поэтому для save_widgets он обязателен: вызов без него снял бы все исключения, и в таблицу поехали бы вопросы, которые автор оттуда убрал. Для save_switchers нужен хотя бы один переключатель — незаданный не трогается, и вызов без обоих ничего бы не изменил.

sync_now досылает всё, что ещё не уехало в таблицу; export_all выгружает накопившиеся ответы заново — новым файлом, новым листом или заменой прежнего.

Опрос без подключённой интеграции — 400 с кодом not_connected.

Zapier

Связки собираются на стороне Zapier — здесь только то, слушает ли он этот опрос. Права и тариф как во всём разделе: опция zapier плюс право integrations.

99. Zapier у опроса

В API с 08.09.2026

{"status": true, "quiz_id": 18547, "connected": true, "is_active": true, "hooks": 2}

hooks — сколько связок на стороне Zapier слушает опрос.

delete сносит и подписки: связка на стороне Zapier перестанет получать ответы, и собирать её придётся заново там же. В ответе — removed_hooks. Опрос без подключения — 400 с кодом not_connected.

Счётчики и пиксели

Google Аналитика, Яндекс.Метрика, пиксель VK и пиксель Meta. У каждого своя тарифная опция (googleStats, yaMetrika, vkPixel, fbPixel) плюс общее для раздела право integrations.

100. Счётчик опроса

В API с 08.09.2026

{service} — google, yandex, vk, fb. Другое значение — 422 с кодом unknown_service.

{"status": true, "quiz_id": 18547, "service": "yandex", "counter": "87654321", "is_active": true}

Номер и признак включённости пишутся и в запись интеграции, и в версию опроса — рендер читает версию. Поэтому включённый счётчик действительно появляется на странице, а после delete копия в версии снимается и счётчик перестаёт вставляться.

Отключение ненастроенного счётчика — 400 с кодом not_connected.

Письма опроса

Копия ответа автору и письмо респонденту. Код подтверждения адреса наружу не отдаётся — это хеш от четырёхзначного числа, то есть девять тысяч вариантов: по нему чужой адрес подтверждается перебором и начинает получать копии ответов.

79. Настройки писем опроса

В API с 08.09.2026

GET/quiz/{id}/emails

Возвращает настройки, получателей копий (без кода подтверждения) и списки вопросов, исключённых из письма автору и из письма респонденту. Поле notifications — правила, сводка, события, напоминание и баллы (§124).

80. Шаблон письма

В API с 08.09.2026

POST/quiz/{id}/emails/template

Поля с приставкой owner_ — письмо автору, client_ — письмо респонденту: subject (до 500), letter (до 5000), use_default_tmpl, reply_to_address, send_promo_code, formatted_letter (HTML из редактора, до 50 000), raw_html + raw_enabled (полностью свой HTML, работает только со своим SMTP). Отдельно client_source — имя скрытой переменной, из которой берётся адрес респондента.

81. Какие вопросы не попадают в письмо

В API с 08.09.2026

POST/quiz/{id}/emails/questions

Непереданный список не трогается — у двух писем исключения независимы. Переданный пустым означает «в письмо идут все вопросы».

UUID сверяется с виджетами черновика опроса: выдуманный или чужой идентификатор даёт 400 с кодом unknown_questions и списком в поле unknown. Раньше такой uuid записывался молча и ни на что не влиял.

Настроек писем у опроса ещё нет — 400 с кодом emails_not_initialized.

82. Включить или выключить письмо

В API с 08.09.2026

POST/quiz/{id}/emails/toggle

Письмо уже в этом состоянии — ответ 200 с unchanged: true: внутри сервис переключает состояние, а не выставляет его, и повторный вызов иначе вернул бы всё как было.

83. Получатели копий ответов

В API с 08.09.2026

Заведённый адрес начинает получать копии только после подтверждения: код уходит на сам адрес, а не выдаётся вызывающему. Подтверждение — action: "confirm" с полем confirmation_code; повторная отправка кода — action: "resend_code".

84. Своя почтовая служба аккаунта

В API с 08.09.2026

Требует отдельное право участника account_smtp: в настройках своей почты лежит пароль от почтового ящика аккаунта.

POST/workspace/{workspace_id}/smtp

Журнал приходит полем logs, рядом — total, limit, offset: имя то же, что у журналов интеграций и вебхуков.

test обращается к почтовому серверу и отвечает 200 с полем connection_ok: неудачная проверка — это её результат, а не сбой вызова.

Тариф: enable и test требуют тарифной опции smtp, без неё — 403 с кодом blocked_by_tariff и blocked_by_tariff: true. show, logs и disable работают на любом тарифе. На тарифе без smtp письма опросов уходят через сервис, даже если свой SMTP включён: настройка сохраняется и снова действует после перехода на тариф с опцией.

Заведение и правка настроек своей почты остаются в кабинете — API их не принимает.

124. Правила, сводка, события, напоминание, баллы

В API с 13.10.2026

POST/quiz/{id}/emails/notifications

Те же настройки, что раздел «Уведомления» в кабинете. Текущие значения — поле notifications в GET /quiz/{id}/emails (всегда полностью, с подставленными значениями по умолчанию).

Передаются только меняемые поля: чего нет в запросе, то не меняется. Объекты digest, events, client_reminder накладываются поверх текущих, null значит «не трогать». rules заменяется списком целиком.

email_ids — email_id из recipients; при отправке учитываются только подтверждённые адреса аккаунта, неизвестные id не ошибка. Значения value по типам вопросов, операторы и что делает сервер по каждому событию — как в кабинете.

Ответ 200: { "status": true, "quiz_id": 1, "notifications": { … } }. Значение вне границ, больше 20 правил или 10 условий — 422.

125. Журнал писем опроса

В API с 13.10.2026

GET/quiz/{id}/emails/logs?limit=20&offset=0

Письма опроса за последние 30 дней, новые сверху: owner, client, booking, rule, digest, event, reminder. Письмо, ещё стоящее в очереди, не видно.

{
  "status": true,
  "quiz_id": 1,
  "total": 42,
  "items": [
    { "id": 931, "kind": "client", "to": "ivan@mail.ru", "subject": "Спасибо за ответ",
      "status": "failed", "error": "Ящик получателя переполнен", "created_at": "2026-10-08T17:58:00+03:00" }
  ]
}

limit — 1–100 (по умолчанию 20), offset ≥ 0; иначе 422 с кодом validation_error. error — понятная причина для failed, null для sent и для неизвестной причины.

Отправить ещё раз: POST /quiz/{id}/emails/logs/{logId}/resend — только для failed, в журнале появится новая запись. 404 с кодом not_found — записи нет в журнале опроса за 30 дней; 422 с кодом not_failed, already_resent (запись уже отправляли повторно — повторяйте новую) или cannot_resend.

126. Пример письма

В API с 13.10.2026

POST/quiz/{id}/emails/{type}/test, type — owner | client.

Письмо в нынешнем виде (тема, шаблон, логотип, отправитель) с выдуманными ответами — на почту пользователя ключа, тема «Пример: …». Ответ 200 с sent_to. Опрос не опубликован — 422 с кодом not_published. Не чаще раза в минуту на пользователя — иначе 429 с кодом too_often; счётчик общий с кабинетом и MCP, отказ 422 его не тратит.

127. Участник аккаунта в получатели

В API с 13.10.2026

POST/quiz/{id}/emails/recipients/member с полем user_id

Добавляет адрес участника аккаунта в получатели копий ответов — сразу подтверждённым, без кода. Ответ 200: email_id, email, checked: true, is_active: true, is_active_booking: true.

Состояние e-mail рассылок

Только чтение. Отправлять и править кампании через API нельзя: письмо уходит живым людям, и отменить его невозможно — такое решение принимает человек.

114. Раздел состояния рассылок

В API с 08.09.2026

GET/workspace/{workspace_id}/mailings

Разделы: campaigns — список кампаний, campaign — одна кампания, recipients — получатели с результатом доставки, contact_lists — списки контактов со сводкой, contacts — контакты одного списка, templates — шаблоны писем, reputation — доля отказов и жалоб (по ней почтовые службы решают, пускать ли письма аккаунта дальше), balance — остаток писем на счету, settings — настройки рассылок, smtp_logs — журнал отправок.

Разделы читаются по одному: каждый обращается к своему сервису, и тянуть их все разом означало бы платить за то, чего не спрашивали.

Кампании или списка с таким идентификатором в аккаунте нет — 400 с кодом not_found и полем section: по нему видно, чего именно нет. Это отсутствие записи, а не сбой чтения.