Журнал изменений

Каждое изменение API указано здесь с версией и датой. Несовместимые изменения выходят только как новая версия пути с уведомлением минимум за двенадцать месяцев.

v1.411.0 · 10 ноября 2026 г.

  • Новое: отчёты о посещаемости для выбора. learning.createAttendanceReport принимает contactListId (класс; учитываются его участники, записанные на курс) или contactIds (от 1 до 500 участников), но не оба; без них, как прежде, все участники. PDF и CSV называют только выбранных. Два действующих отчёта не могут пересекаться только для одного и того же человека (409 period-overlaps), и attendance-finalized действует только для людей в отчёте. Если в выборе нет участников: no-participants. Каждый отчёт содержит selection (course, contactList, contacts), contactListId и contactIds.

v1.410.0 · 10 ноября 2026 г.

  • Новое: события learning.attendance.minimumAtRisk (минимальную посещаемость курса можно достичь, только посетив все оставшиеся занятия) и learning.attendance.minimumUnreachable (её больше нельзя достичь), один раз для каждой стадии, курса и контакта, проверка ежедневно, только для курсов вашей организации. Данные содержат только идентификаторы и числа: courseId, sharedCourseId (null), contactId, attendedCount, pastCount, totalCount, requiredCount, minimumPercent; тот же расчёт, что и status в learning.getCourseAttendance.

v1.409.0 · 10 ноября 2026 г.

  • Новое: зафиксированные отчёты о посещаемости. learning.createAttendanceReport (POST /learning/courses/{id}/attendance-reports) фиксирует список курса за период (from, to, календарные дни включительно) или без них за весь курс и выпускает PDF с кодом проверки (document); каждое занятие периода с датой должно уже пройти (409 sessions-pending), хотя бы одно должно попадать в период (no-sessions), и ни один действующий отчёт не может иметь общий день (409 period-overlaps). learning.listAttendanceReports, learning.getAttendanceReport (с зафиксированными sessions и data), learning.getAttendanceReportCsv и learning.cancelAttendanceReport (аннулирует и PDF). Отметки к занятиям действующего отчёта learning.createAttendanceEntry и learning.revokeAttendanceEntry отклоняют с 409 attendance-finalized. Пока отчёты в среде не включены, фиксация даёт feature-not-available с reason: "attendance-reports-disabled".

v1.408.0 · 10 ноября 2026 г.

  • Новое: посещаемость класса. learning.getContactListAttendance (GET /contact-lists/{id}/learning-attendance) возвращает для каждого текущего участника класса и урока-занятия всех курсов, доступных классу через доступ, те же ячейки, что и learning.getCourseAttendance, а также посещения и status по каждому курсу и посещения и процент по всем курсам. У каждого занятия есть courseId и sharedCourseId (null для собственных курсов); если у участника нет выдачи курса, там стоит notParticipant: true и ячеек нет. learning.getContactListAttendanceCsv возвращает тот же список в формате CSV. Только чтение; отметки и отчёты ведутся в каждом курсе.

v1.407.0 · 10 ноября 2026 г.

  • Новое: управление профилями каталога. finder.listProfiles (GET /finder/profiles) возвращает все профили специалистов организации в любом состоянии, с фильтрами status и contactId; публичное представление остаётся GET /finder/practitioners. finder.deleteProfile (DELETE /finder/profiles/{id}, право finder:write) окончательно удаляет архивный профиль вместе с запросами, проверками, сертификатами и адресами и сообщает в ответе их количество; профиль в другом состоянии даёт 409 conflict с reason: "profile-not-archived".
  • Изменено: contacts.merge (POST /contacts/{id}/merge) больше не завершается ошибкой из-за архивного профиля каталога. Он удаляется при объединении вместе с запросами, проверками, сертификатами и адресами; остаётся не более одного профиля (неархивный, иначе профиль сохраняемого контакта, иначе изменённый последним). 409 с practitioner-profiles-on-multiple теперь возникает, только если встретились бы два неархивных профиля.

v1.406.0 · 9 ноября 2026 г.

  • Новое: отметки посещаемости. learning.createAttendanceEntry отмечает для урока-занятия «очно» (onSite, засчитывается как посещение и отмечает урок выполненным) или «уважительная причина» (excused) с указанием причины; не более одной на участника и урок (409 already-recorded). learning.revokeAttendanceEntry отменяет отметку и возвращает её с revokedAt. Каждая ячейка списка посещаемости содержит entry. Список, его CSV и отметки принимают в качестве {id} и courseId курса по совместному доступу (learning.listSharedCourses), без встречи поставщика. Пока отметки в среде не включены, добавление даёт feature-not-available с reason: "attendance-entries-disabled".

v1.405.0 · 9 ноября 2026 г.

  • Новое: посещаемость курса. learning.getCourseAttendance возвращает для каждого участника и урока-занятия минуты и долю во время встречи (измерено в онлайн-комнате, только время от начала до конца), measurement (upcoming, measured, absent, notMeasured, cancelled), посещение, процент и status относительно минимальной посещаемости завершения (onTrack, atRisk, unreachable); learning.getCourseAttendanceCsv — тот же список в формате CSV. Только для курсов вашей организации; для курса по совместному доступу пока ответ not-found (появится вместе с ручными отметками).
  • Изменено: урок-занятие считается посещённым, только если участник был в онлайн-комнате во время встречи (только время от начала до конца), а не просто в открытой комнате до или после неё. Это сразу влияет на состояние урока в learning.getCourseParticipant, а также на completedCount в learning.getCourseProgress, learning.listCompletions и событие learning.course.completed, если завершение зависит от уроков-занятий. Уже зафиксированные уроки остаются выполненными; правило действует со следующей фиксации.

v1.404.0 · 9 ноября 2026 г.

  • Новое: повторная отправка разрешённых, но не отправленных счетов. POST /invoices/plan-runs/resend (тело как у release, runId) и POST /invoices/resend-released (ids, от 1 до 200) отправляют только разрешённые, ещё не отправленные счета, с 200 и { sent, notSent, notSentInvoices, skipped }: notSent как при разрешении (причина → количество), notSentInvoices по каждому счёту с id, number и reason (ключ логики отправки), skipped для идентификаторов без такого счёта. Только ORG_ADMIN. Новое в GET /invoices/plan-runs: releasedNotSent по каждому прогону.
  • Изменено: GET /invoices/plan-runs показывает прогон и тогда, когда waiting равно 0, а releasedNotSent больше 0. Автоматически отправленные счета (последующие по подписке, разрешение досланных счетов и счетов по планам, первое списание) после отправки получают статус SENT и создают событие invoices.invoice.sent, как отправка через POST /invoices/{id}/send; раньше они оставались ISSUED без события.

v1.403.0 · 9 ноября 2026 г.

  • Новое: условия оплаты для многих контактов. POST /contacts/billing-defaults/update (scope contacts:write) задаёт стандартные условия оплаты для contactIds (от 1 до 500) или для всех результатов filter с полями GET /contacts (q, type, tag, responsible, directDebitMandate), ровно одно из двух; paymentTermId: null снимает собственные. Ответ { matched, unchanged, overwritten, updated } с 200. POST /contacts/billing-defaults/update/preview (scope contacts:read) считает с тем же телом без изменений, { matched, unchanged, overwritten }. Более 5 000 результатов: 422 precondition-failed, reason: too-many-contacts, с matched. Архивные условия оплаты считаются ненайденными (404). Как и PATCH /contacts/{id}/billing-defaults, не создаёт событий. Новое в GET /contacts: directDebitMandate=valid|notValid — контакты с действующим SEPA-мандатом на прямое дебетование или без него (статус GUELTIG и не истёк через 36 месяцев без использования).

v1.402.0 · 7 ноября 2026 г.

  • Изменено: доступы, выдачи, классы у доступа и доступы у товара теперь работают с одним из прав LERN_BIBLIOTHEK (библиотека) или LERN_KURSE (курсы), как их показывает GET /organization/entitlements; раньше только с LERN_BIBLIOTHEK. Затронуты: learning.listAccesses, learning.createAccess, learning.updateAccess, learning.archiveAccess, learning.unarchiveAccess, learning.listGrants, learning.grantAccess, learning.revokeAccess, learning.revokeAccessOfContact, learning.getAccessContactLists, learning.setAccessContactLists, learning.getArticleAccesses, learning.setArticleAccesses. Подборке в доступе по-прежнему нужно LERN_BIBLIOTHEK, курсу LERN_KURSE; создание доступа с подборкой И курсом требует обоих, иначе feature-not-available. Исключение: learning.setAccessCollections и learning.setAccessCourses с пустым списком работают с любым из двух прав. Действия автоматизаций lern-zugang-gewaehren и lern-zugang-entziehen вызывают learning.grantAccess и learning.revokeAccessOfContact и следуют тому же правилу.

v1.401.0 · 7 ноября 2026 г.

  • Новое: responsibleContactId (nullable) у курса (learning.getCourse, learning.listCourses, learning.updateCourse): контакт, который ведётся как преподаватель; он отвечает на вопросы и работы в портале в разделе «Как преподаватель». Оба поля исключают друг друга; установка одного очищает другое. Оба со значением одновременно дают invalid_combination, контакт без записи преподавателя — not-found в body.responsibleContactId.
  • Новое: feedback.contactId (nullable) у каждого раунда в learning.getSubmission: преподаватель-контакт, если отзыв дан в портале; тогда userId равен null.

v1.400.0 · 7 ноября 2026 г.

  • Новое: sharedCourseId (nullable) у каждой работы (learning.listSubmissions, learning.getSubmission) и каждого завершения (learning.listCompletions), а также в событиях learning.submission.submitted, learning.submission.reviewed и learning.course.completed: предоставление, если курс принадлежит другой организации (сразу к learning.getSharedCourse), для собственных курсов null.
  • Новое: certificateTemplateId также у каждой записи learning.listSharedCourses, а не только в learning.getSharedCourse.

v1.399.0 · 7 ноября 2026 г.

  • Новое: learning.setSharedCourseCertificate задаёт ваш собственный шаблон сертификата для предоставленного курса или удаляет его (null); уже завершившие без сертификата получают его задним числом (issuedCount). Кроме того, certificateTemplateId в learning.getSharedCourse. Шаблон организации-поставщика у вас не действует.
  • Изменено: learning.listCourseParticipants, learning.getCourseParticipant, learning.completeParticipantLesson, learning.reopenParticipantLesson, learning.getCourseProgress и learning.resetQuizAttempts принимают также courseId предоставленного курса (из learning.listSharedCourses); участники — ваши контакты с выдачей через это предоставление. learning.getCourse для этого идентификатора по-прежнему возвращает 404.
  • Изменено: learning.listSubmissions и learning.listCompletions возвращают также работы и завершения по предоставленным курсам; их courseId — идентификатор курса организации-поставщика, фильтр courseId действует на оба вида. Тот же идентификатор стоит в learning.submission.* и learning.course.completed.

v1.398.0 · 6 ноября 2026 г.

  • Новое: learning.releaseSharedCourseItem открывает часть (course, module, lesson) предоставленного курса для всех, у кого сейчас есть к нему доступ: для каждого одно вмешательство «Открыть сейчас» с причиной (released считает их, 0 не ошибка). Кроме того, waitsForAppointment у курса, каждого модуля и каждого урока в learning.getSharedCourse.
  • Изменено: в предоставленных курсах условие «после встречи» организации-поставщика отображается у вас как manual (никогда как afterAppointment). Его видно по waitsForAppointment в learning.getSharedCourse; открыть можно через learning.releaseSharedCourseItem или learning.createIntervention.
  • Изменено: learning.createIntervention теперь принимает также курс, модуль и урок предоставленного курса, если доступ выдачи включает это предоставление.

v1.397.0 · 6 ноября 2026 г.

  • Новое: курсы, которые другие организации предоставили вашей организации. learning.listSharedCourses (с providerName, createdAt, endedAt, active; завершённые предоставления, пока у вас действуют доступы), learning.getSharedCourse (заголовок и структура только для чтения, в форме собственных курсов) и learning.setAccessSharedCourses. sharedCourseIds у каждого доступа и в learning.createAccess. Завершённое предоставление нельзя добавить заново (422 shared-course-ended), неизвестное сообщается в body.sharedCourseIds.

v1.396.0 · 6 ноября 2026 г.

  • Новое: предоставление курсов другим организациям, сторона поставщика. learning.listCourseShareConnections (активные подключения для предоставления курсов), learning.listCourseShares (предоставления курса с participantCount — числом участников с действующим доступом в другой организации, без имён), learning.shareCourse (201, created) и learning.endCourseShare (действующие там доступы продолжаются до окончания; уже завершено: 409 already-ended). Только администраторы. Ошибки: 404 connection-unknown, 422 connection-not-active, connection-revoked, connection-wrong-purpose, course-not-published.
  • Изменено: learning.archiveCourse завершает предоставления курса другим организациям; действующие там доступы продолжаются до окончания. Восстановление (learning.unarchiveCourse) не открывает их снова.

v1.395.0 · 6 ноября 2026 г.

  • Новое у каждой подборки (learning.listCollections, learning.createCollection, learning.updateCollection и все ответы с подборкой): recommendation («Подходит к этому», та же форма, что у курса: другая подборка, курс или своя ссылка), задаётся при создании и изменении; null удаляет рекомендацию, если поля нет — она остаётся. Подборка не может рекомендовать саму себя (422 в recommendation.collectionId).

v1.394.0 · 6 ноября 2026 г.

  • Новое у каждого курса (learning.*Course*): withoutLearningControl («Без контроля обучения»: нет вопросов преподавателю и нет уроков-заданий; тесты и уроки-встречи остаются; по умолчанию false), задаётся в learning.createCourse и learning.updateCourse. Включение, пока в курсе есть уроки-задания (включая черновики): 422 precondition-failed с assignments-present, lessonIds (не более 100) и assignmentCount.
  • Изменено: в курсе с withoutLearningControl learning.createLesson с type: "assignment" отклоняется (422 precondition-failed, without-learning-control), а импорт курса не создаёт уроки-задания из источника и не переводит уроки в задания; они перечислены в kept с reason: "without-learning-control". Клиентам следует обрабатывать неизвестные причины в kept в общем виде.

v1.393.0 · 6 ноября 2026 г.

  • Новое в learning.getAppointmentMaterial и learning.updateAppointmentMaterial: recordingCollectionId (действующая подборка записи) и переопределение recordingCollectionOverride ({ collectionId } или null = как у вида приёма; «без подборки» на приёме не бывает, неизвестна: 422 в body.recordingCollectionOverride.collectionId с not-found). Если действующая подборка меняется без recordingFolderOverride, на приёме снова действует папка вида приёма.
  • Новое: learning.addAppointmentRecordings (POST /appointments/{id}/learning-material/recordings) задним числом помещает готовые видеозаписи приёма без учебного материала как черновики в подборку, папку и со сроком приёма; ответ 200 с created и recordings. 422 recording-consent-incomplete (исправляется confirmIncompleteConsent: true) и no-target-collection. Плюс список recordings в learning.getAppointmentMaterial (только то, что доступ может видеть).
  • Изменено: visibleDaysAfterRelease теперь можно задавать в learning.createContent и learning.updateContent (от 1 до 3650 или null), и он действует для любого материала, а не только для записей; раньше только чтение у записей. Недопустимо: 422 в body.visibleDaysAfterRelease.

v1.392.0 · 6 ноября 2026 г.

  • Новое в местах подписантов шаблона PDF (templates.getPdf, templates.updatePdf, signerSlots): contactId — предлагаемый контакт с адресом электронной почты, который подписывает по ссылке электронной подписи (например, преподаватель, не являющийся участником). Место содержит userId или contactId, никогда оба. Если контакта нет или у него нет адреса электронной почты: 422 в body.signerSlots с invalid_reference.
  • Новое в выданных документах (letters.getIssued и прочие ответы с документом, signature.slots): suggestedContactId — контакт, который шаблон предлагает для места (null, если он предлагает участника или никого).

v1.391.0 · 6 ноября 2026 г.

  • Изменённое поведение: если задача относится к повторному контакту из списка звонков (её создаёт пайплайн), карточка следует за ней: PATCH /tasks/{id} с новым dueDate переносит повторный контакт карточки; status DONE, DELETE /tasks/{id} или dueDate: null снимают его (отложенная карточка его сохраняет); при повторном открытии он возвращается со сроком задачи. Это относится и к POST /tasks/{id}/status. Другие поля карточку не меняют.

v1.390.0 · 6 ноября 2026 г.

  • Изменено: для случая Metabolic Balance засчитывается самая новая отправка анкеты, ещё не использованная прежним случаем этой карты клиента, даже если она пришла до начала случая; раньше — только после начала. form.responseId/form.submittedAt в clients.listMetabolicBalanceCases и startMetabolicBalanceCase, а также передача (…/handover, …/handover/send) следуют этому правилу; submittedAt может быть раньше startedAt. Это относится и к уже идущим случаям.
  • Изменено: в передачу в Metabolic Balance (…/handover, bloodValues, и …/handover/send) попадают только значения из утверждённых результатов, считанных или введённых вручную; раньше хватало считанного, даже черновика. Отклонённые результаты нигде не учитываются. В случае (report) результаты, введённые вручную, учитываются после отправки; если всё считано, но ещё не всё утверждено, шаг report сообщает об этом.

v1.389.0 · 5 ноября 2026 г.

  • Новое в learning.getAppointmentTypeMaterial и learning.setAppointmentTypeMaterial: recordingFolderId (папка целевой подборки для записи, null = верхний уровень; не в подборке: 422) и recordingVisibleDays (видна N дней после открытия, от 1 до 3650, null = без срока). Если recordingCollectionId меняется без новой папки, папка становится null.
  • Новое в learning.getAppointmentMaterial и learning.updateAppointmentMaterial: действующие recordingFolderId и recordingVisibleDays, а также переопределения recordingFolderOverride ({ folderId } или null = как у вида приёма) и recordingVisibleDaysOverride ({ days } или null). Папка, которой больше нет в подборке, действует как верхний уровень.
  • Новое в материале: visibleDaysAfterRelease (только чтение, только для записей, иначе null). Изменённое поведение в представлении контакта: запись со сроком больше не показывается через столько дней после открытия контакту (поиск с contactId, медиа); открытие остаётся в learning.listReleases, а материал — в библиотеке организации.

v1.388.0 · 5 ноября 2026 г.

  • Изменённое поведение: материал после занятия (запуск в конце приёма и learning.releaseAppointmentMaterial) получают по каждому материалу все с действующим доступом к его подборке, независимо от записи на приём; при attendeesOnly — присутствовавшие с доступом. Раньше его получали записанные, а не ответившие выпадали. recipientCount считает разные контакты.
  • Изменённое поведение: открытие материала публикует неопубликованное (кроме черновиков). При attendeesOnly оно остаётся неопубликованным и в представлении контакта видно только получателям; отсутствовавшим такой материал не показывается, даже по расписанию подборки.

v1.387.0 · 5 ноября 2026 г.

  • Преподаватели проводят приёмы: resourceId в appointments.create (и в сериях приёмов) теперь принимает и преподавателя (teacher у ресурса), для любого типа приёма и в любое время, без состава и без рабочего времени; проверяется только, нет ли у него уже приёма в это время (иначе 409 conflict с slot-taken). appointments.reschedule сохраняет преподавателя приёма и без resourceId. Онлайн-приёмы преподавателя получают живую комнату. Раньше такой resourceId отвечал ошибкой, что ресурс не относится к типу приёма.

v1.386.0 · 5 ноября 2026 г.

  • Преподаватели (контакт, проводящий занятия как ведущий, без свободного времени): GET, PUT и DELETE /appointment-teachers/{contactId} (appointments.getTeacher, appointments.setTeacher, appointments.removeTeacher). getTeacher возвращает isTeacher, resourceId, removable, upcomingCount и ближайшие не более 20 приёмов (upcoming с participantCount, без имён); контакт, который не преподаватель, отвечает isTeacher: false. setTeacher повторяем и отвечает 200; removeTeacher отвечает 204, при будущих приёмах 409 conflict с reason upcoming-appointments и extra.count. Отсутствующий или чужой контакт даёт 404, компания — validation-failed в params.contactId с code not-a-person. У каждого ресурса новое поле teacher (appointments.listResources, appointments.getResource).

v1.385.0 · 5 ноября 2026 г.

  • Новое: POST /clients/{id}/metabolic-balance-client/plans/{planId}/copy-pdf (clients.copyMetabolicBalancePlanPdf, без тела, 200) переносит PDF плана связанного клиента из Metabolic Balance в карту клиента как защищённую копию, только по этому явному вызову для каждого плана. Ответ { planId, documentId, copiedAt, created }; если PDF уже в карте (своя копия или PDF случая), приходит тот же идентификатор с created: false, ничего не загружается заново. Причины: 404, если план не принадлежит связанному клиенту; 422 metabolic-balance-client-not-linked и metabolic-balance-plan-without-pdf (с extra.planState); 409 metabolic-balance-pdf-failed (с extra.error) и metabolic-balance-copy-in-progress (зависшая попытка истекает через пять минут).
  • Новое в clients.listMetabolicBalanceClientPlans для каждого плана: documentId — PDF плана в карте (PDF случая или перенесённая копия), иначе null; файл через documents.downloadUrl.

v1.383.0 · 5 ноября 2026 г.

  • Новое: данные в Metabolic Balance в карте клиента. GET /clients/{id}/metabolic-balance-client (clients.getMetabolicBalanceClient) показывает, с каким клиентом в MBG связана карта (без связи: 200 с linked: false). GET …/metabolic-balance-client/candidates (clients.searchMetabolicBalanceClients, search от 2 до 100 символов) ищет во всём аккаунте MBG: не более 10 кандидатов, анонимизированных никогда, с порядком match. PUT …/metabolic-balance-client (clients.linkMetabolicBalanceClient, { patientId }, 200) связывает только по этому явному вызову; сначала claritos читает клиента в MBG: 422 validation-failed в body.patientId, 409 metabolic-balance-client-linked-elsewhere с extra.clientId. DELETE …/metabolic-balance-client (clients.unlinkMetabolicBalanceClient, 204) удаляет только связь в claritos. GET …/metabolic-balance-client/plans (clients.listMetabolicBalanceClientPlans) и …/blood-tests (clients.listMetabolicBalanceBloodTests, сначала новые, не более 20) читают в MBG при каждом вызове, ничего не сохраняется; без связи { data: [] }.
  • Если карта связана, …/handover/send берёт этого клиента и не проверяет дубликаты; если коуч при отправке выбирает или создаёт клиента, карта без связи связывается с ним.

v1.381.0 · 5 ноября 2026 г.

  • Новое: POST /clients/{id}/metabolic-balance-cases/{caseId}/handover/release-plan (clients.releaseMetabolicBalancePlan, { phase, allowedTreatMeals, allowedOils }, 200) утверждает план в MBG и передаёт его клиенту; claritos отправляет клиенту письмо без сведений о здоровье и показывает план в его клиентском портале. Уведомляет ли MBG клиента сам, пока неизвестно; claritos не отменяет передачу; никогда дважды, повторный вызов после частичной ошибки продолжает. Причины: 422 metabolic-balance-not-generated (с extra.planState), 409 metabolic-balance-already-released, а также известные.
  • Новое в mbg передачи: releaseDefaults (значения плана в MBG как предзаполнение) и releasedAt.

v1.380.0 · 5 ноября 2026 г.

  • Новое: чат проверки с бэк-офисом Metabolic Balance. GET /clients/{id}/metabolic-balance-cases/{caseId}/handover/chat (clients.listMetabolicBalanceChatMessages) читает последние 100 сообщений, сначала старые, в MBG при каждом вызове (claritos не сохраняет сообщения; чтение ничего не отмечает как прочитанное; без чата пустой список). POST …/handover/chat (clients.postMetabolicBalanceChatMessage, { text }, 200) отправляет сообщение; 409 metabolic-balance-no-chat без чата. От повторной отправки защищает Idempotency-Key.
  • Новое в mbg передачи: chatAvailable и chatUnreadSince.

v1.379.0 · 5 ноября 2026 г.

  • Новое в mbg передачи: planDocumentId (PDF плана в карте, копируется в защищённое хранилище, как только план создан в MBG; если MBG создаёт его заново, claritos заменяет файл под тем же идентификатором, а если это не удаётся, остаётся прежний) и planPdfError (no-pdf, fetch-failed, not-a-pdf, too-large; после пяти неудач больше не пытается). Файл получают через documents.downloadUrl с этим идентификатором, только для ключей с доступом к данным клиентов; собственные ссылки MBG claritos никогда не выдаёт.

v1.378.0 · 5 ноября 2026 г.

  • Новое: POST /clients/{id}/metabolic-balance-cases/{caseId}/handover/generate-plan (clients.generateMetabolicBalancePlan) создаёт план в Metabolic Balance. Каждый вызов, который создаёт план, стоит один план на счёте организации в MBG; тело требует confirmCost: true, повторный вызов никогда не создаёт дважды. Ответ 200 с передачей. Причины: 422 metabolic-balance-not-sent, metabolic-balance-not-ready (с extra.checkErrors); 409 metabolic-balance-already-generated (с extra.planState), а также известные.
  • Новое в mbg передачи: generationRequestedAt, verificationReason (наши ключи), blockReason (текст MBG, не более 500 символов) и lastCheckedAt. claritos запрашивает планы, которые чего-то ждут (создание, проверка): вскоре после создания и каждые пять минут.

v1.377.0 · 5 ноября 2026 г.

  • Новое: POST /clients/{id}/metabolic-balance-cases/{caseId}/handover/laboratory (clients.createMetabolicBalanceLaboratory) создаёт новую лабораторию в управлении лабораториями коуча в Metabolic Balance и выбирает её в случае. Профиль ввода берётся из отчёта: единица и нормальный диапазон для пола клиента, иначе значения MBG; без персональных данных. Ответ 200 с передачей. 409 metabolic-balance-laboratory-exists с extra.laboratoryId, если лаборатория с таким названием уже есть (выбрать через PATCH …/handover); если не удалось только сохранить профиль, повторный вызов продолжает. Другие причины: 422 metabolic-balance-not-connected, validation-failed (например body.countryId); 409 case-closed, metabolic-balance-rejected, metabolic-balance-unavailable.
  • Новое в передаче (GET, PATCH, send): options.countries (страны из MBG) и options.reportLaboratory (name, matchedLaboratoryId, suggestedCountryId).

v1.376.0 · 5 ноября 2026 г.

  • Изменено: affiliates.createCoupon (POST /affiliate-coupons), affiliates.updateCoupon (PATCH /affiliate-coupons/{id}) и affiliates.updateClimateContribution (PUT /affiliate-climate-contribution) требуют права AFFILIATE_VERWALTUNG (см. GET /organization/entitlements). Без него они отвечают 403 feature-not-available с reason affiliate-license, как affiliates.activity. Исключение: updateCoupon с active: false (выключение) работает и без этого права, так же как affiliates.deleteCoupon и affiliates.disableTracking. То же правило действует в приложении.

v1.375.0 · 5 ноября 2026 г.

  • Новое: POST /clients/{id}/metabolic-balance-cases/{caseId}/handover/send отправляет передачу в Metabolic Balance: создаёт клиента и план или берёт существующие, передаёт все разделы и анализ крови, спрашивает MBG, можно ли создать план. Ничего не создаётся. Повторный вызов продолжает и ничего не создаёт дважды. Сначала claritos ищет клиента в аккаунте MBG; совпадение никогда не берётся молча: 409 metabolic-balance-duplicate с не более чем пятью кандидатами в extra.candidates, затем выбор через patient ({ mode: "existing", patientId } или { mode: "new" }). Затем claritos спрашивает об открытом черновике в MBG, созданном не в этом случае (MBG допускает один на клиента): 409 metabolic-balance-draft-exists с extra.draft (planId, createdAt, state), и здесь до любой записи; взять и перезаписать через overwriteDraftPlanId, при втором вызове вместе с patient. Другие причины: 422 handover-incomplete (с extra.missing), collection-too-old, metabolic-balance-not-connected; 409 case-closed, metabolic-balance-rejected (с extra.providerMessage), metabolic-balance-unavailable.
  • Новое в передаче (GET, PATCH, send): mbg с клиентом и планом в MBG (patientId, planId), planState в наших ключах, canGenerate, checkErrors как от MBG, sentAt, outOfGlobalRange; null, пока не отправлено.

v1.374.0 · 5 ноября 2026 г.

  • Изменено: couplings.prospectsRequired в pipelines.update (PATCH /pipelines/{id}) считается выполненным, как только у интересанта есть любая карточка в пайплайне организации, в любом состоянии (открыта, отложена, закрыта), а не только карточка в этом пайплайне. Просьбу о привязке или, с prospectsAutomatic, карточку получает только интересант совсем без карточки. Так у одного человека не появляется двух карточек.
  • Изменено: перенос по обязательности (pipelines.getBackfill и pipelines.startBackfill, GET/POST /pipelines/{id}/backfill) теперь берёт только интересантов без единой карточки в организации; у кого уже есть карточка в другом пайплайне, даже закрытая, тот больше не добавляется. candidates считается так же.

v1.373.0 · 5 ноября 2026 г.

  • Импрессум и политика конфиденциальности: дополнения к постоянно формируемому шаблону. GET /organization/legal-texts указывает у каждого элемента mode, supplements и sections (для других видов null), а также dpoNotAppointed. Новое: PUT /organization/legal-texts/{kind}/supplements. DELETE /organization/legal-texts/{kind} отбрасывает собственный текст; дополнения сохраняются, без дополнений как прежде. PATCH /organization/legal-texts принимает dpoNotAppointed. isCustomized по-прежнему истинно только для собственного текста (то же, что mode own), одни дополнения его не меняют; version повышается и при изменении дополнений.

v1.371.0 · 5 ноября 2026 г.

  • Новое: чтение и подготовка передачи случая в Metabolic Balance. GET /clients/{id}/metabolic-balance-cases/{caseId}/handover возвращает разделы как в портале MB со статусом (ready, unclear, optional, attention), настройки плана, варианты выбора (options: лаборатории, языки, списки MBG), показатели крови с единицей из результатов в написании MBG (без пересчёта) и двумя уровнями (outside-norm, outside-global), свободные ответы анкеты для сопоставления и blockers. PATCH по тому же пути частично меняет настройки и сопоставления. Свои ключи: dietGoal none/lose/regulation/gain, healthTrigger в camelCase; идентификаторы Metabolic Balance берутся из options. Пока ничего не отправляется.

v1.370.0 · 5 ноября 2026 г.

  • Новое: POST /clients/{id}/metabolic-balance-cases/{caseId}/request-report повторно запрашивает у клиента результаты анализов. Вызов сразу пишет клиенту по каналу случая, со ссылкой для загрузки; если результаты уже считаны, сообщение называет недостающие обязательные показатели. Если прежний запрос файлов больше не принимает загрузки, создаётся новый (затем в fileRequest). Каждый вызов пишет снова. Ответ 200 со случаем; 409 case-closed или send-failed, 422 case-not-sent, contact-without-email, sender-missing, metabolic-balance-not-connected.
  • Новое в объекте случая (GET и POST /clients/{id}/metabolic-balance-cases): report с фазой (none, reading, redaction, failed, read), requiredCount, receivedCount, missing, optionalRequested, optionalReceived в виде { key, name } (key как markerKey в biomarkers.listProfileItems) и lastRequestedAt. Результаты, связанные во вкладке лаборатории с направлением случая, тоже учитываются.

v1.369.0 · 5 ноября 2026 г.

  • Новое: случаи Metabolic Balance в карте клиента. GET /clients/{id}/metabolic-balance-cases показывает случаи с их состоянием (отправка, анкета, результаты анализов, передача, план). POST /clients/{id}/metabolic-balance-cases начинает случай: утверждает направление на анализы из профиля, выдаёт ссылку на анкету и создаёт запрос файлов для результатов (channel email или portal). Сообщение клиенту уходит в фоне, как только готовы PDF направления; поэтому delivery.sentAt появляется позже и читается через GET. Требуются право METABOLIC_BALANCE (иначе 403 metabolic-balance-license) и подключённый доступ (иначе 422 metabolic-balance-not-connected); один открытый случай на карту (409 case-open).

v1.368.0 · 5 ноября 2026 г.

  • Новое право METABOLIC_BALANCE (подключение к порталу Metabolic Balance) в GET /organization/entitlements и в эндпоинтах лицензий. У него нет предварительных условий, оно открывает подключение к порталу в настройках организации; ключ вводится там, а не через API.
  • GET /organization/integrations показывает для бизнес-организаций подключение metabolicBalance (настройки в bereich=schnittstellen): без права METABOLIC_BALANCE со state not-enabled, иначе not-connected, faulty (последняя проверка не удалась) или connected.

v1.367.0 · 4 ноября 2026 г.

  • Новое: courseId в learning.searchCourses ограничивает поиск одним курсом.
  • Поиск по курсам теперь находит и страницы PDF-файлов урока (matchIn: "pdfPage") с новым полем lessonMaterialId; для страниц PDF-материала самого урока оно остаётся null.

v1.366.0 · 4 ноября 2026 г.

  • Типы приёма можно дублировать: POST /appointment-types/{id}/duplicate (appointments.duplicateType, область appointments:write, то же право, что и createType) создаёт неактивную копию: к названию на каждом сохранённом языке добавляется «(Kopie)», «(copy)» или «(копия)», slug новый (…-kopie, …-kopie-2); ответ 201 с копией. Копируется настройка вместе с составом и услугами; бренд, форма, сценарий разговора, место, телефон, план напоминаний и ссылка оплаты ссылаются на те же объекты. Приёмы, ссылки для записи и доступ для партнёров не копируются (partnerRelease NONE). Если оригинал ссылается на сценарий, ссылку оплаты или план напоминаний, которые createType не принял бы, возвращается та же ошибка.

v1.365.1 · 4 ноября 2026 г.

  • Исправлено: includeArchived=false в pipelines.list (GET /pipelines) и pipelines.listSlas (GET /pipelines/slas) раньше тоже возвращал архивные записи (любое непустое значение считалось true). Теперь параметр принимает true или false.

v1.365.0 · 4 ноября 2026 г.

  • Курсы могут называть два уровня своей структуры (levelNames: first для модулей, second для подмодулей); название задаётся на языке запроса и переводится, как остальные тексты курса; null или пустая строка возвращает все языки к значению по умолчанию. Названия не содержат номера: портал нумерует сам и только там, где номера нет в названиях.

v1.364.0 · 4 ноября 2026 г.

  • Обучающая платформа, курсы: description и instructor.description теперь форматированный текст (HTML; обычный текст по-прежнему допускается и превращается в абзацы) и принимают в learning.createCourse и learning.updateCourse до 20 000 символов вместо 5 000. claritos очищает HTML при сохранении. Поведение: кто до сих пор показывал description как обычный текст, теперь видит разметку вроде <p>; перед показом обрабатывайте её как HTML. Импорт курсов (learning.startCourseImport) теперь тоже очищает оба текста при сохранении и превращает обычный текст в абзацы; ограничение в 20 000 символов там не действует. Если текст превышает 20 000 символов только после очистки, createCourse/updateCourse сообщает too_big у поля.

v1.363.0 · 4 ноября 2026 г.

  • Обучающая платформа, папки курсов и курсы в коллекциях: новые конечные точки learning.listCourseFolders, createCourseFolder, updateCourseFolder, moveCourseFolder, deleteCourseFolder (папки курсов, не более двух уровней, без правила открытия), learning.orderCourseItems (POST /learning/courses/order) и listCollectionCourses, addCollectionCourse, updateCollectionCourse, removeCollectionCourse (курс плиткой в коллекции; не даёт доступа). Новое у курса: folderId, position и collections; learning.updateCourse принимает folderId. Новое у папок коллекций: courseCount; learning.deleteFolder сообщает movedCourseCount; learning.orderItems знает type course. Поведение: папки, материалы и плитки курсов одного уровня коллекции теперь делят числа в position. Импорт не создаёт папок курсов и не перемещает уже упорядоченное.

v1.362.0 · 4 ноября 2026 г.

  • Обучающая платформа, поиск по курсам: новая конечная точка learning.searchCourses (GET /learning/courses/search), дополнение. Ищет в курсах, модулях и уроках (заголовки, описания, имя, строка и текст преподавателя, тексты уроков, речь и страницы PDF их медиа); плоские строки как у learning.searchContents, с type (course, module, lesson), modulePath и lessonType; с contactId с точки зрения контакта (locked, unlockReasons), без него с draft. learning.searchContents остаётся без изменений и НЕ возвращает находок из курсов; кому нужно и то и другое, вызывает оба поиска.

v1.361.0 · 4 ноября 2026 г.

  • Обучающая платформа, курсы: у instructor два новых поля, jobTitle (строка под именем на карточке в портале, по языкам) и imageAssetId (фото из медиатеки, null = инициалы); в ответе всегда, в learning.updateCourse необязательно. Дерево импорта (learning.startCourseImport) не содержит ни фото, ни jobTitle; последующий импорт оставляет оба как есть. Новое поле recommendation («Подходит к этому», не более одной записи, oneOf по type: коллекция, другой курс или собственная ссылка с заголовком и изображением), в ответе всегда (null без записи), в learning.updateCourse необязательно (null удаляет её); learning.createCourse его не задаёт. Если цель удалена, запись равна null.

v1.360.0 · 4 ноября 2026 г.

  • Обучающая платформа, перемотка вперёд: новое поле allowSeeking (boolean, по умолчанию true) у коллекции (чтение, learning.createCollection, learning.updateCollection) и у курса (чтение, learning.updateCourse). При false портал разрешает в видео и аудио переход только до самого дальнего уже просмотренного места. Поведение: прогресс за одно сообщение растёт не больше, чем на время с предыдущего сообщения (умноженное на 1,25, плюс 15 секунд); одно сообщение больше не отмечает видео как просмотренное. При true, то есть у всех существующих коллекций и курсов, прогресс ведёт себя как прежде; ограничение действует только при false.

v1.359.0 · 3 ноября 2026 г.

  • Размер тела запроса для каждой конечной точки: learning.startCourseImport (POST /learning/course-imports) теперь принимает до 4 МБ (4 194 304 байта), все остальные вызовы по-прежнему до 1 МБ. До сих пор каркас отклонял любое тело больше 1 МБ с 413, в том числе при импорте курса, для которого обещано 4 МБ; курс примерно из 250 уроков на этом не прошёл. Каждая операция с телом указывает свой предел в спецификации как x-max-body-bytes, а ответ 413 (payload-too-large) называет его в поле maxBodyBytes. Размер считается в байтах (UTF-8), в том числе для запроса без Content-Length.

v1.358.0 · 3 ноября 2026 г.

  • Обучающая платформа, материалы урока: learning.createLessonMaterial (POST /learning/lessons/{id}/materials, 201) прикрепляет файл из медиатеки (без title название медиафайла, не более 50, сверх того conflict с too-many-materials), learning.updateLessonMaterial и learning.deleteLessonMaterial (/learning/lesson-materials/{id}), learning.orderLessonMaterials (POST …/materials/order). Материал из импорта не изменяется (conflict, material-from-import); удалённый вернётся при следующем импорте, добавленные вручную любой импорт оставляет. Новое поле materials в каждом ответе с уроком, всегда присутствует ([] без материалов), у каждого материала media как у урока.

v1.357.0 · 3 ноября 2026 г.

  • Биомаркеры, переименовано до выпуска: поля-счётчики в biomarkers.listAxes (и в ответах createAxis, updateAxis, orderAxes) называются draftEntryCount, lockedEntryCount и ruleCount вместо draftEntries, lockedEntries и rules, как markerCount и ruleCount в этой области (1.356.0 не было ни в одной среде).

v1.356.0 · 3 ноября 2026 г.

  • Биомаркеры, оси вручную: оси профилей биомаркеров теперь можно вести без импорта файла профиля. Новые biomarkers.listAxes (GET /biomarker-axes, с числом записей в черновиках draftEntryCount и в утверждённых, отозванных или принятых профилях lockedEntryCount, правил ruleCount, deletable, deleteBlockedBy), biomarkers.createAxis (POST; без key следующий свободный, например «A18»; занятый ключ даёт 409 axis-key-taken, ключ order не допускается), biomarkers.updateAxis (PATCH /biomarker-axes/{key}, название и заметка; ключ остаётся), biomarkers.orderAxes (PUT /biomarker-axes/order, каждый ключ ровно один раз, возвращает упорядоченный список) и biomarkers.deleteAxis (DELETE; записи в черновиках теряют ось; 409 axis-in-locked-profile, пока её называет утверждённый, отозванный или принятый профиль, axis-in-rule, пока её использует правило). Для записей: biomarkers.listProfileItems (GET /biomarker-profiles/{id}/items, маркер, пол, axisKey, familyKey, assignment) и biomarkers.setItemAxis (PUT /biomarker-profiles/{id}/items/{itemId}/axis, только в собственных черновиках, иначе 409 profile-not-draft или profile-licensed; axisKey: null снимает привязку; возвращает запись, как listProfileItems); изменение ставит assignment в ACHSE_FESTGELEGT.

v1.355.0 · 3 ноября 2026 г.

  • Обучающая платформа, курсы в доступе: learning.setAccessCourses (PUT /learning/accesses/{id}/courses) задаёт курсы доступа, заменяет список в переданном порядке и не трогает подборки; неизвестный курс даёт not-found в body.courseIds, без права на курсы feature-not-available. Новое поле courseIds в ответах доступа и выдачи, всегда присутствует ([] без курсов), и необязательно в learning.createAccess (пустой список не требует права). Черновики и архивные курсы как у подборок. События без изменений.

v1.354.0 · 3 ноября 2026 г.

  • Обучающая платформа, создание курса: learning.createCourse (POST /learning/courses, 201) создаёт пустой курс, черновиком с открытием сразу и без source; последующий импорт его не затрагивает. Поля title (обязательно), description, type и selfPacedStart как в learning.updateCourse, ответ как у learning.getCourse с пустой структурой.

v1.353.0 · 3 ноября 2026 г.

  • Разговоры, ответственный и привязка: inbox.listConversations и inbox.getConversation теперь содержат assigneeUserId, ответственного (участник организации; только пока он участник), и relatedTo, к чему относится разговор, как объединение по type. Сейчас есть только { type: "lesson", courseId, lessonId }: вопрос, который клиент задал по уроку в портале; ответственный тогда преподаватель курса (responsibleUserId, 1.352.0). Если курс или урок удалён, там null. Без ответственного или привязки оба поля равны null, то есть у всех прежних разговоров. Новый фильтр assigneeUserId в inbox.listConversations, assigneeUserId=none для разговоров без ответственного. Назначение ответственного появится в одной из следующих версий.

v1.352.0 · 3 ноября 2026 г.

  • Обучающая платформа, преподаватель курса: у курсов есть responsibleUserId, участник организации, которому приходят вопросы из портала по урокам этого курса (assigneeUserId разговора); null = никто. Задаётся через learning.updateCourse; не участник даёт not-found в body.responsibleUserId. Если человек покидает организацию, значение остаётся, но считается как никто. Не зависит от instructor (отображаемого преподавателя).
  • Лицензия, поведение (спецификация не меняется): для лицензий с версией (model: version) право LIVE_RAUM теперь следует из уровня видео организации (включён, забронирован или как отдельное исключение у тенанта со Start); отдельное разрешение у организации больше не нужно. Версии больше не показывают LIVE_RAUM в choiceList и как бронируемый модуль (bookable); это действует при чтении для каждой версии, в том числе уже опубликованной, а бронирование модуля отклоняется (conflict, reason rejected). Новые сохранённые версии его тоже не содержат. Бронируются уровни видео. Лицензии без версии (model: existing) не меняются.

v1.351.0 · 3 ноября 2026 г.

  • Лицензия, уровни видео с названием и версией: рядом с ключом (tier) теперь название на языке запроса (tierName; собственные уровни со своим названием, START, PLUS, PRO с постоянным текстом) в organization.getLicenseChoices (также в ответах setLicenseChoices и setVideoTier: video.tierName, video.booked[].tierName), organization.getLicense (modules[].tierName, bookable[].tierName, perOrganization[].videoTierName) и в предпросмотре смены периода (modules[].tierName). Номер версии уровня указан там, где организация видит свой уровень: video.tierVersionNumber, perOrganization[].videoTierVersionNumber, а в bookable[] версия, которую сегодня получило бы новое бронирование (tierVersionNumber). Ключ собственного уровня создаётся из его первого названия и потом не меняется, поэтому показывайте название.

v1.350.0 · 3 ноября 2026 г.

  • Переписки: новый канал portal (channel в inbox.listConversations и inbox.getConversation, фильтр channel=portal, channels.portal в inbox.getConversationCounts). Он охватывает сообщения в клиентском портале в разделе «Общение», по одной переписке на цепочку; защищённая почта карты не появляется. subject это тема цепочки, counterpart равен null, сообщения в истории содержат HTML. Клиенты, которые ветвятся по channel, получают новое значение.

v1.349.0 · 3 ноября 2026 г.

  • Обучающая платформа, текст с пропусками и пул вопросов: type вопроса теста получает значение blanks (текст с пропусками); клиентам, которые ветвятся по типу, нужна для него ветка. Новое у вопроса: blanks (для каждого пропуска answers, допустимые ответы; null для single и multiple, для blanks options пуст). Пропуски стоят в тексте как {{1}}, {{2}} …, начиная с 1; сравнение без учёта регистра, пробелы объединяются. learning.createQuestion и learning.updateQuestion принимают type blanks с blanks (от 1 до 20 пропусков, по 1–10 ответов до 100 символов); метки, не соответствующие пропускам, дают invalid в body.blanks, пропуск без ответа — required в body.blanks[i].answers, слишком много или слишком длинные ответы — too-large. PUT /learning/questions/{id}/answers для текста с пропусками даёт wrong-type в params.id. Новое у теста: questionsPerAttempt (пул вопросов: столько вопросов каждая попытка выбирает случайно, null все; при сохранении не больше, чем вопросов в тесте, иначе invalid в body.questionsPerAttempt; если позже вопросы удалят, каждая попытка берёт все). Импорт и getCourseMissing остаются с single и multiple.

v1.348.0 · 3 ноября 2026 г.

  • Обучающая платформа, расширенный тест: у теста урока (learning.updateQuiz, читается у урока) новые maxAttempts (максимум попыток на человека, от 1 до 100, null без ограничения; сброшенные не учитываются), timeLimitMinutes (от 1 до 600, null без ограничения; считается на сервере с «Начать тест» в портале, после истечения и небольшого допуска отправка считается несданной) и showSolution (never по умолчанию как раньше, afterSubmit, afterPass: когда портал показывает правильные ответы). Вне границ — invalid в body.maxAttempts или body.timeLimitMinutes. learning.getCourseParticipant содержит для каждого урока-теста quiz с attemptCount, lastScore, passed, remainingAttempts (иначе null). Новый POST /learning/courses/{id}/participants/{contactId}/lessons/{lessonId}/quiz-attempts/reset (learning.resetQuizAttempts): попытки остаются в истории, но больше не учитываются; текущая попытка завершается; урок, не являющийся тестом, даёт wrong-type в params.lessonId.

v1.347.0 · 3 ноября 2026 г.

  • Сертификаты и PDF-шаблоны: новый вид поля TRIGGER_VALUE в pdfFieldKind (templates.*, letters.getIssued) для значения, которое процесс передаёт при выдаче; binding сейчас только course.title, название курса при его завершении на учебной платформе. При выдаче вручную такое поле остаётся пустым. Клиенты, которые ветвятся по kind, получают новое значение. У сертификата новые sourceKind (COURSE_COMPLETION) и sourceId (id из learning.listCompletions или completionId из learning.course.completed), если его выдал процесс без вошедшего в систему человека, иначе оба null. Одно завершение даёт не более одного сертификата.

v1.346.0 · 3 ноября 2026 г.

  • Обучающая платформа, участники: GET /learning/courses/{id}/participants (learning.listCourseParticipants, по имени, фильтр active как true/false, с lessonCount, completedLessonCount, progressPercent, lastActivityAt, completedAt, grantId действующей выдачи) и GET /learning/courses/{id}/participants/{contactId} (learning.getCourseParticipant: для каждого урока status completed/open/locked, completedAt, completedManually, unlocksAt, unlockReasons, а также interventions). Отметить вручную: POST …/participants/{contactId}/lessons/{lessonId}/complete с reason (learning.completeParticipantLesson, уже пройденный остаётся без изменений) и …/reopen (learning.reopenParticipantLesson, только отмеченные вручную, иначе 422 precondition-failed с reason not-manual). Вмешательства в личное расписание (в том числе для библиотеки): POST /learning/grants/{id}/interventions (learning.createIntervention, 201, объединение по type: pause с startDate/endDate, move с targetType/targetId/date, releaseNow с targetType/targetId, extendEnd с endDate; reason обязательна; раздел, не относящийся к выдаче, даёт not-found в body.targetId), GET /learning/grants/{id}/interventions (learning.listInterventions) и POST /learning/interventions/{id}/revoke (learning.revokeIntervention, можно повторять). GET /learning/courses/{id}/progress (learning.getCourseProgress): для каждого урока startedCount и completedCount, а также participantCount. unlockReasons при afterItem теперь содержат targetType.

v1.345.0 · 3 ноября 2026 г.

  • Обучающая платформа, завершение и сертификат: у курса (learning.getCourse, записывается через PATCH /learning/courses/{id}) новое completionRule с requiredLessons (all все уроки, кроме черновиков, selected только requiredLessonIds) и minAttendancePercent (от 1 до 100 % уроков-занятий с округлением вверх; при all занятия тогда учитываются через долю; null без требования), задано всегда, в PATCH заменяет всё правило; а также certificateTemplateId (PDF-шаблон, templates.getPdf). Урок вне курса даёт not-found в body.completionRule.requiredLessonIds[i], процент вне диапазона invalid, неизвестный шаблон not-found, отключённый invalid в body.certificateTemplateId. Новый GET /learning/completions (learning.listCompletions): завершения, сначала изменённые последними, фильтры courseId, contactId, updatedSince, с certificate (status none/pending/issued/failed, issuedDocumentId читается через letters.getIssued, failureReason). Новое событие learning.course.completed (один раз для участника и курса). Если у курса есть шаблон, сертификат выдаётся при завершении (status issued с issuedDocumentId, при ошибке failed с failureReason); если команда задаёт шаблон, завершения без сертификата получают его задним числом.
  • Автоматизации: триггеры learning.course.completed, learning.submission.submitted и learning.submission.reviewed можно ограничить курсами (фильтр courseId, вид course, «один из»), например чтобы запускать следующий шаг только при завершении определённого курса.

v1.344.0 · 3 ноября 2026 г.

  • Обучающая платформа, работы: GET /learning/submissions (learning.listSubmissions) перечисляет работы участников в уроках типа assignment, сначала изменённые последними, с фильтрами courseId, lessonId, contactId, status (submitted, returned, accepted) и updatedSince; черновики никогда. GET /learning/submissions/{id} (learning.getSubmission) возвращает сданные попытки с текстом, файлами (documentId, filename, mimeType, sizeBytes; скачать через GET /documents/{id}/download-url) и отзывом на каждую попытку. POST /learning/submissions/{id}/feedback (learning.createSubmissionFeedback, 201) даёт отзыв на последнюю сданную попытку: result accepted завершает урок, returned возвращает работу, grade по желанию; без сданной попытки 422 precondition-failed с reason not-submitted, если отзыв уже есть, already-answered. Новые события learning.submission.submitted и learning.submission.reviewed.
  • Автоматизации: триггер learning.submission.reviewed можно фильтровать по результату отзыва (result: accepted, returned), например чтобы запускать следующий шаг только для принятых работ.

v1.343.0 · 3 ноября 2026 г.

  • Обучающая платформа, типы курсов: type (selfPaced, class) теперь можно задать в PATCH /learning/courses/{id} (learning.updateCourse); новое поле selfPacedStart (access с доступом, по умолчанию; firstOpen при первом открытии в портале), читается у курса и записывается. Действует только при selfPaced и сохраняется у курса для класса; курс для класса начинается в общий день старта класса, через который пришёл участник, а без даты старта класса с доступом. «С дня n» и immediately считаются от этого старта; старт в будущем закрывает доступ до него.
  • Обучающая платформа, уроки-занятия: POST /learning/courses/{id}/lessons (learning.createLesson) принимает type: "appointment"; appointmentId в createLesson и PATCH /learning/lessons/{id} (learning.updateLesson, null убирает его); для урока другого типа invalid, встреча, которой нет в организации, not-found, каждый раз в body.appointmentId. Новые GET /learning/lesson-appointments/options (learning.lessonAppointmentOptions: активные виды встреч с kind и capacity, действующие серии) и GET /learning/lesson-appointments (learning.listLessonAppointments: встречи для выбора, ровно один из appointmentTypeId и recurrenceId, без них required, оба invalid; сначала предстоящие, постранично через cursor). В правилах курса теперь можно выбрать afterAppointment; встреча вне организации даёт not-found в body.rule.conditions[i].appointmentId.

v1.342.0 · 3 ноября 2026 г.

  • Классы, общий старт: GET /contact-lists, GET /contact-lists/{id}, POST /contact-lists и PATCH /contact-lists/{id} содержат startDate, общий старт класса как календарный день yyyy-mm-dd в часовом поясе организации (null: старт ещё не задан); курсы платформы обучения для этого класса начинаются в этот день. PATCH /contact-lists/{id} (contacts.updateList) теперь принимает { name?, startDate? }, хотя бы одно из двух (иначе validation-failed с required); startDate: null удаляет старт, несуществующий день или год вне диапазона 2000–2100 дают validation-failed для body.startDate, и тогда название тоже не меняется. У подгрупп старта нет.

v1.341.0 · 2 ноября 2026 г.

  • Обучающая платформа, правила доступа для элементов курса: rule и display в PATCH /learning/courses/{id} (learning.updateCourse; у курса всегда заданы, по умолчанию сразу), PATCH /learning/modules/{id} и PATCH /learning/lessons/{id} (learning.updateModule, learning.updateLesson; null = собственного нет, действует правило уровнем выше) и в их ответах; hasOwnRule у модулей и уроков в learning.getCourse. В курсе afterItem указывает на module или lesson, а afterQuiz.quizId это идентификатор урока типа quiz. Ссылка, которой нет в курсе, даёт not-found, элемент, ждущий сам себя или то, что под ним, cycle, урок другого типа в afterQuiz wrong-type, каждый раз в body.rule.conditions[i]. POST /learning/releases/preview (learning.previewRule) вместо collectionId принимает и courseId (с moduleId или lessonId); ровно одно из двух.
  • Схема условия общая и становится шире: afterItem.targetType теперь знает также module и lesson. Правила подборки, её папок и материалов никогда не содержат module/lesson (там они отклоняются с invalid в body.rule.conditions[i].targetType), правила курса никогда не содержат collection/content. Эндпоинты выдачи доступа (targetType в listReleases, release, withdrawRelease) остаются с collection/content.

v1.340.0 · 2 ноября 2026 г.

  • У типов встреч в liveRoom теперь есть waitingRoom (AUTO, ON, OFF; по умолчанию AUTO): зал ожидания в live-комнате claritos. Все, кроме ведущего и со-модераторов, ждут, пока встреча не начнётся в прямом эфире. AUTO оставляет решение live-комнате по типу: включён для занятий и групповых встреч, иначе выключен. Если поле не указано в PATCH, сохранённое значение остаётся. Действует при каждом входе, то есть и для уже забронированных встреч; если ведущий переключит его в комнате, это важнее. Чтение в appointments.getType/listTypes, запись в createType/updateType.

v1.339.0 · 2 ноября 2026 г.

  • Обучающая платформа: курс из GoHighLevel теперь можно импортировать в интерфейсе и как подборку библиотеки; каждый урок становится открытой записью, пока не назначен файл. Новое: GET /learning/collections/{id}/missing (learning.getCollectionMissing, открытые и закрытые записи с path и expectedType), PUT /learning/collection-entries/{id}/media (learning.setCollectionEntryMedia, создаёт материал; идемпотентно для того же файла, 409 для другого, wrong-type или media-not-ready в body.assetId), POST /learning/collection-entries/{id}/dismiss и /reopen (learning.dismissCollectionEntry, learning.reopenCollectionEntry, 204).
  • Запуски импорта курсов (learning.getCourseImport, learning.listCourseImports, learning.startCourseImport) теперь содержат targetType (course или collection) и collectionId. Запуск теперь может быть и подборкой (только из импортёра GoHighLevel в интерфейсе): тогда courseId пуст, хотя запуск не завершился ошибкой, а missingVideos считает открытые записи. listCourseImports фильтрует по targetType; для подборок событий learning.courseImport.* нет.

v1.338.0 · 2 ноября 2026 г.

  • Обучающая платформа, структура курса: модули через POST /learning/courses/{id}/modules (learning.createModule), PATCH /learning/modules/{id} (learning.updateModule), POST /learning/modules/{id}/move (learning.moveModule), DELETE /learning/modules/{id} (learning.deleteModule; без cascade подмодули и уроки перемещаются на уровень выше, с ?cascade=true удаляются, ответ с movedLessonCount, movedModuleCount, при cascade также deletedLessonCount, deletedModuleCount), POST /learning/courses/{id}/modules/order (learning.orderModules). Уроки через GET/PATCH/DELETE /learning/lessons/{id} (learning.getLesson, learning.updateLesson, learning.deleteLesson с 204), POST /learning/courses/{id}/lessons (learning.createLesson), POST /learning/lessons/{id}/move (learning.moveLesson), POST /learning/courses/{id}/lessons/order (learning.orderLessons). Тест через PATCH /learning/lessons/{id}/quiz (learning.updateQuiz: passMark, passedText, failedText), POST /learning/lessons/{id}/questions (learning.createQuestion), PATCH/DELETE /learning/questions/{id} (learning.updateQuestion, learning.deleteQuestion с 204), POST /learning/lessons/{id}/questions/order (learning.orderQuestions). Третий уровень модулей возвращает validation-failed с code too-deep в body.parentId, неподходящие ответы — invalid в body.options.
  • Исправлено: includeArchived=false в learning.listAccesses, learning.listCollections, learning.listContents и learning.listCourses раньше тоже возвращал архивные записи (любое непустое значение считалось true). Теперь параметр принимает true или false.

v1.337.0 · 2 ноября 2026 г.

  • Обучающая платформа, курсы: новые эндпоинты GET /learning/courses (learning.listCourses), GET/PATCH /learning/courses/{id} (learning.getCourse со структурой, learning.updateCourse), POST /learning/courses/{id}/publish (learning.publishCourse; если не хватает видео или правильных ответов, 422 с reason course-incomplete, missingVideoCount, missingAnswerCount, исправляется через confirmIncomplete: true), POST /learning/courses/{id}/archive и /unarchive, GET /learning/courses/{id}/missing (learning.getCourseMissing), PUT /learning/lessons/{id}/media (learning.setLessonMedia, 409, если медиафайл уже есть) и PUT /learning/questions/{id}/answers (learning.setQuestionAnswers, correctIndexes как позиции с 0).

v1.336.0 · 2 ноября 2026 г.

  • Обучающая платформа, импорт курса: claritos теперь загружает файлы импорта (изображения, видео, аудио, материалы) в медиатеку. Новое в каждой записи files[] (GET /learning/course-imports/{id}, learning.listCourseImports): failureReason (только при failed: not-https, blocked-network, too-large, timeout, wrong-type, source-error, invalid-url, dns-failed, too-many-redirects, connection-aborted, empty, internal-error), httpStatus (только при source-error) и assetId (при done). Новое counts.filesPending, также в событии learning.courseImport.completed: файлы поступают после этого события, filesPending > 0 означает, что загрузка ещё идёт. Видео и аудио до 2 ГиБ, остальное до 200 МБ.

v1.335.0 · 2 ноября 2026 г.

  • Обучающая платформа, классы в доступе: новые эндпоинты GET /learning/accesses/{id}/contact-lists (learning.getAccessContactLists) и PUT /learning/accesses/{id}/contact-lists (learning.setAccessContactLists, полный набор contactListIds, ответ с grantedCount и revokedCount). Выбранный класс выдаёт доступ всем текущим участникам (source class), убранный завершает только эти выдачи (событие learning.access.ended с reason class); выдачи из других источников сохраняются. Новое поле contactListIds у доступа. learning.listAccesses теперь также возвращает notifyOnGrant, как и запрос одного доступа.

v1.334.0 · 2 ноября 2026 г.

  • Обучающая платформа, папки в подборках (два уровня: папка и подпапка): новые эндпоинты GET/POST /learning/collections/{id}/folders (learning.listFolders, learning.createFolder), PATCH/DELETE /learning/folders/{id} (learning.updateFolder, learning.deleteFolder с movedContentCount и movedFolderCount; материалы и подпапки поднимаются на уровень выше), POST /learning/folders/{id}/move (learning.moveFolder) и POST /learning/collections/{id}/items/order (learning.orderItems, папки и материалы одного уровня). Новое поле folderId у материалов (чтение, createContent, addContents, updateContent; null = верхний уровень), folderPath у результатов поиска и folderId в learning.previewRule. Третий уровень отклоняется с кодом too-deep. learning.orderContents по-прежнему упорядочивает только переданные материалы.

v1.333.0 · 2 ноября 2026 г.

  • Новое: ключи доступа контакта к клиентскому порталу GET /contacts/{id}/portal-passkeys (contacts.getPortalPasskeys, contacts:read): passkeyCount, lastUsedAt и для каждого ключа data[] с id (идентификатор записи в claritos, а не идентификатор учётных данных), label (поставщик или устройство), createdAt, lastUsedAt. Открытые ключи и идентификаторы учётных данных API никогда не выдаёт. Также DELETE /contacts/{id}/portal-passkeys (contacts.removePortalPasskeys, contacts:write): удаляет все ключи доступа, например после потери телефона; затем человек снова входит с кодом. Ответ { removedCount } со статусом 200, без ключей removedCount: 0; неизвестный контакт not-found.

v1.332.0 · 2 ноября 2026 г.

  • Беседы, тон: каждая беседа в GET /inbox/conversations и GET /inbox/conversations/{id} содержит sentiment (positive, neutral, negative, null = ещё не оценено), тон последнего оценённого входящего письма. Новый фильтр sentiment (positive, neutral, negative, none = ещё не оценено); он устанавливает канал email, потому что SMS никогда не оцениваются. GET /inbox/conversation-counts дополнительно возвращает sentiments { positive, neutral, negative, none } по открытым беседам по email.

v1.331.0 · 2 ноября 2026 г.

  • Обучающая платформа, импорт курса: новые эндпоинты POST /learning/course-imports (learning.startCourseImport, 202), GET /learning/course-imports/{id} (learning.getCourseImport) и GET /learning/course-imports (learning.listCourseImports, фильтры sourceSystem, sourceCourseId). Программа отправляет курс целиком (модули, подмодули, уроки, тесты с правильными ответами; файлы адресом), claritos импортирует его в фоне как черновик; повторный импорт из того же источника дополняет его. Новые события learning.courseImport.completed и learning.courseImport.failed (с reason).

v1.330.0 · 2 ноября 2026 г.

  • Обучающая платформа, несколько материалов сразу: новый эндпоинт POST /learning/collections/{id}/contents (learning.addContents) с assetIds (от 1 до 50 файлов медиатеки). Для каждого файла создаётся неопубликованный материал в конце подборки, в порядке assetIds; название берётся из имени файла в медиатеке. Ответ 201 { created, failed }; ошибка с одним файлом не останавливает остальные, failed называет причину для каждого файла (not-found, media-not-ready, limit-reached, failed).

v1.329.0 · 2 ноября 2026 г.

  • Обучающая платформа, письмо о новом доступе: каждый доступ содержит notifyOnGrant (по умолчанию включено, задаётся в POST /learning/accesses и PATCH /learning/accesses/{id}). Если оно включено, контакт получает письмо со ссылкой на портал, как только доступ начинает для него действовать. Каждая выдача также содержит accessEmailStatus (pending, sent, skipped, failed), accessEmailSkipReason (при skipped: disabled, alreadyActive, noEmail, companyWithContacts, ambiguousEmail, beforeIntroduction) и accessEmailAt.

v1.328.0 · 2 ноября 2026 г.

  • Обучающая платформа, записи без полного согласия на курс: POST /learning/contents с документом живого сеанса, на который согласились не все участники, отвечает 422 precondition-failed с reason recording-consent-incomplete, consentedCount, participantCount и fixable: true; с новым полем confirmIncompleteConsent: true материал создаётся, а подтверждение фиксируется. Каждый материал также содержит consentConfirmation (null или confirmedAt, consentedCount, participantCount, confirmedByUserId, confirmedByApiKeyId).

v1.327.0 · 2 ноября 2026 г.

  • Обучающая платформа, поиск: GET /learning/contents/search (q от 2 до 100 символов, limit от 1 до 100, без постраничного вывода). Результаты в названии, описании, речи (positionMs) и страницах PDF (pdfPage), поле matchIn, excerpt. С contactId только то, что видит этот контакт, заблокированные результаты с locked и unlockReasons; без него вся библиотека, включая черновики (draft). Слишком короткий запрос: 422 validation-failed в query.q.

v1.326.0 · 2 ноября 2026 г.

  • Обучающая платформа, материал после занятия: GET/PUT /appointment-types/{id}/learning-material (список из библиотеки, который открывается в конце каждого приёма этого вида, recordingCollectionId для записи как черновика, attendeesOnly), GET/PATCH /appointments/{id}/learning-material (add, hide, отличающийся attendeesOnly, withheld; ответ с releasedAt и recipientCount) и POST /appointments/{id}/learning-material/release (открыть сейчас; при «только присутствовавшие» без измерения 422 precondition-failed, reason attendance-not-measured). Открытия сообщаются через learning.content.released с source appointment.

v1.325.0 · 2 ноября 2026 г.

  • Обучающая платформа: у подборок есть notifyDelivery — настройка команды для уведомлений участникам (bellOnly, push, emailNow, emailDaily, emailWeekly, sms; null — настройка claritos, то есть недельный обзор). Чтение в GET /learning/collections, запись через POST /learning/collections и PATCH /learning/collections/{id}. Колокольчик в портале добавляется всегда; каждый участник может изменить это для себя. При notify: false поле не учитывается.

v1.324.0 · 2 ноября 2026 г.

  • Обучающая платформа: вся библиотека через API. Подборки (GET/POST /learning/collections, PATCH /learning/collections/{id}, …/publish, …/archive и …/unarchive, POST /learning/collections/order) с правилом открытия rule (match all или any, не более пяти conditions: immediately, afterDays, fromWeek, onDate, afterItem, afterQuiz, afterAppointment, fromLevel, manual), показом display и сроком duration. Материалы (GET /learning/collections/{id}/contents, POST /learning/contents из медиатеки assetId, документа или ссылки https, PATCH, …/media для новой версии, …/publish, …/archive, …/unarchive, порядок) с использованием releasedTo/seenBy. Создание и ведение доступов (POST /learning/accesses, PATCH, …/archive, …/unarchive, PUT …/collections). Открытия: GET /learning/releases, POST /learning/releases (вручную), POST /learning/releases/withdraw, POST /learning/releases/preview (расчёт правила заранее, ничего не записывает). Доступы артикула: GET/PUT /articles/{id}/learning-accesses.

v1.323.0 · 2 ноября 2026 г.

  • Новое: переписки, цепочки писем и истории SMS в одном списке. GET /inbox/conversations фильтрует по представлению (open, starred, closed), каналу, почтовому ящику, непрочитанным, тегу контакта или группе тегов (contactTagMode any/all), кампании (campaignId: ответы после отправки, как в отчёте кампании) и поиску; sort waiting ставит первыми тех, кто ждёт дольше всех (waitingSince); листание через cursor и limit, как везде. GET /inbox/conversations/{id} возвращает историю, POST /inbox/conversations/update устанавливает сразу для многих read, unread, star, unstar (для лица, стоящего за ключом), а также close и reopen (для всех), с results для каждого идентификатора (updated, notFound), GET /inbox/conversation-counts даёт числа по представлениям, каналам, ящикам, тегам контактов и кампаниям, PUT /inbox/conversations/{id}/contact назначает контакт. inbox.listThreads и связанные эндпоинты не меняются.

v1.322.0 · 2 ноября 2026 г.

  • Новое в автоматизациях: два действия платформы обучения. «Предоставить доступ к платформе обучения» вызывает POST /learning/grants, «Отозвать доступ к платформе обучения» вызывает POST /learning/grants/revoke; второе отзывает только доступы, выданные вручную, через API или автоматизацией, доступы из покупки или класса остаются. GET /automation-catalog указывает оба, поле accessId с источником learningAccess. Кроме того, события learning.access.granted и learning.access.ended передают дни доступа как grant.startDate и grant.endDate, как доступ в GET /learning/grants.

v1.321.0 · 2 ноября 2026 г.

  • Новая область learning (обучающая платформа, права learning:read и learning:write): GET /learning/accesses перечисляет доступы, GET /learning/grants выдачи контакта или доступа, POST /learning/grants выдаёт доступ (можно повторять; через API с источником api, из автоматизации с источником automation), POST /learning/grants/{id}/revoke отзывает его с причиной, POST /learning/grants/revoke отзывает доступ у контакта. Отзываются только выдачи, созданные вручную, через API или автоматизацией; выдачи из покупки или класса отвечают 422 precondition-failed с reason grant-source-protected. Требует права организации LERN_BIBLIOTHEK, иначе 403 feature-not-available.

v1.320.0 · 2 ноября 2026 г.

  • Новое: три события платформы обучения для вебхуков и автоматизаций. learning.access.granted, когда контакт получает доступ, из любого источника (grant.source: manual, api, automation, purchase или class). learning.access.ended, когда доступ действительно заканчивается, при отзыве или по истечении срока, в том числе позднее, с grant.endedAt и grant.reason (manual, api, automation, payment, cancelled, ended, class или expired). learning.content.released, когда подборка или материал становится доступным контакту (release.targetType collection или content, release.source rule, appointment или manual). Одно событие на контакт; полезная нагрузка содержит идентификаторы, названия и время, без прогресса обучения. События отправляются, как только платформа обучения начнёт работу.

v1.319.0 · 2 ноября 2026 г.

  • Три новых права для обучающей платформы в GET /organization/entitlements и в эндпоинтах лицензий: LERN_BIBLIOTHEK (библиотека), LERN_KURSE (курсы) и LERN_COMMUNITY (сообщество). У них нет предварительных условий; эндпоинты самой обучающей платформы последуют.
  • DELETE /articles/{id} теперь также отвечает 409 in-use, если покупка товара даёт доступ к обучающей платформе (usage.learningAccesses).

v1.318.0 · 1 ноября 2026 г.

  • Новое: ответы из CRM через домен SendGrid. PUT /sendgrid/domains/{id}/crm-replies с enabled выбирает домен с готовым разделом ответов (не более одного; другой домен теряет выбор) или снимает выбор; у домена есть поле crmReplies. Адрес для ответа на письма из контакта тогда — отправитель перед @ на хосте ответов (собственное имя отправителя, иначе часть его адреса отправителя перед @, только если однозначно, иначе адрес для ответов организации); ответ попадает к этому человеку. Без готового раздела ответов 422 precondition-failed с reason sendgrid-replies-not-set-up; в production до дополнения политики конфиденциальности reason sendgrid-personal-not-released.

v1.317.0 · 1 ноября 2026 г.

  • Новое: внесение согласия на напоминания о встречах POST /contacts/{id}/reminder-service/subscribe (contacts.subscribeReminders, contacts:write), пара к contacts.unsubscribeReminders, например для согласия, полученного при онбординге до первой встречи. Тело: channels (email, sms; без указания оба, если у контакта есть значение) и note (обязательно, как было дано согласие). Ответ как у getReminderService плюс revocationKept: каналы, от которых контакт отказался сам; там ничего не вносится. Действующее лицо сохраняется в записи; без него no-acting-user; без значения у контакта validation-failed.

v1.316.0 · 1 ноября 2026 г.

  • Изменено, спецификация та же: conversation.sendEmail, conversation.getComposeOptions и conversation.checkPermission работают и для контакта с картой клиента без разрешения на данные клиентов (раньше 404 not-found). Письмо является обычным письмом переписки и попадает в общие исходящие; сообщения в карту клиента тогда недоступны. Историю переписки такого контакта (conversation.list, getEntry, getReplyBasis) по-прежнему читает только тот, у кого есть разрешение. q в GET /outbound-emails ищет каждое слово отдельно в теме, адресе получателя и имени контакта, которому ушло письмо, умлауты также в написании с e. Рассылки: новая рассылка начинается с выключенной защитой клиентов (clientProtection.enabled false); POST /email-campaigns/{id}/client-protection с enabled: false требует данных клиентов и clients:read, только если письма рассылки уже находятся в разделе клиентов.

v1.315.0 · 1 ноября 2026 г.

  • Новое: со-модераторы групповых встреч. POST /appointments/{id}/co-moderators/check перед приглашением показывает для каждой встречи free, busy или already; POST /appointments/{id}/co-moderators приглашает сотрудника (userId) или контакт (contactId), scope appointment или series (эта и все следующие встречи серии; последующие встречи серии получают его автоматически), занятые и уже приглашённые встречи перечислены в skipped; POST /appointments/{id}/co-moderators/remove отзывает приглашение (removed). Со-модератор получает собственное приглашение с файлом календаря и ссылкой, в live-комнате claritos он со-ведущий с момента входа и не занимает место; время сотрудника с ресурсом резервируется. 422 co-moderator-without-email, not-a-group-appointment, appointment-not-open. Участники содержат isCoModerator (side PROVIDER); hosts и фильтр contactId в GET /appointments не учитывают со-модераторов.

v1.314.0 · 1 ноября 2026 г.

  • У типов встреч появилось поле practiceRelevant (по умолчанию false): относится ли тип встречи к работе практики? Только тогда его письма в организации с практикой попадают в исходящие раздела клиентов, иначе в общие исходящие (letters.listEmails). Чтение в appointments.getType/listTypes, запись в createType/updateType. При переключении уже отправленные письма переносятся. Выключение только с доступом к данным клиентов (clients:read, разрешено для API), иначе 403 forbidden с reason practice-off-needs-client-access. Изменено, спецификация та же: встречи по телефону, в практике или с выездом на дом больше не получают видеокомнату; meetingUrl там остаётся пустым.

v1.313.0 · 1 ноября 2026 г.

  • Изменено в языке правил, спецификация та же: имя в формуле, которое является основным названием ровно одного лабораторного показателя, означает этот показатель, даже если другие показатели содержат его как поисковый термин ({{Kreatinin}} — креатинин сыворотки, больше не mehrdeutigerName). Два показателя с одинаковым основным названием остаются неоднозначными. formula в ответах о правилах содержит имя, только если при чтении оно ведёт к той же цели, иначе идентификатор ({{loinc:2160-0}}, {{G-A1-01}}); каждую formula можно отправить обратно без изменений. Лабораторные показатели типа индекс или отношение без собственной единицы в формулах без единицы ({{HOMA-IR}} >= 2,5); раньше подпись системного каталога считалась единицей и возвращалось einheitFehlt.

v1.312.0 · 31 октября 2026 г.

  • Новое в автоматизациях: фильтр по ответу в форме для триггера forms.response.submitted. В trigger.filter для этого указывается response.answers.‹поле› со значением ключа варианта ответа; поле и вариант такие же, как в GET /forms/{id}/analysis (поле имеет вид вид:идентификатор, например def:… или std:…). Фильтр срабатывает, если ответ содержит вариант, при множественном выборе также наряду с другими; да/нет передаются как true или false. Не более десяти таких записей на правило, совпасть должны все. GET /automation-catalog указывает фильтр с kind formAnswer и path response.answers. Анкеты карты клиента не передают ответы, там фильтр никогда не срабатывает.

v1.311.0 · 31 октября 2026 г.

  • Изменено: DELETE /appointments/{id}/participants/{contactId} удаляет и последнего участника занятия или группового приёма «только внутренний»; приём остаётся со свободными местами. Раньше здесь возвращалось last-participant (на мероприятии последний и раньше мог уйти). Исключённый участник, как и прежде, получает отмену.

v1.310.0 · 31 октября 2026 г.

  • Новое: облако слов свободных ответов в GET /forms/{id}/analysis. Каждый вопрос со свободным текстом содержит terms (items с term, display, count, kind word, pair или answer, а также belowThreshold и hidden), подсчитанные без ИИ: по ответам, начиная с 3 ответов, не более 40, без адресов электронной почты, веб-адресов, телефонов, чисел и служебных слов; у других вопросов terms: null. Новое на верхнем уровне: hiddenTerms. PUT /forms/{id}/analysis/hidden-terms с terms заменяет список скрытых понятий (только администраторы, forms:write); отдельное слово скрывает и все пары слов, в которых оно стоит.

v1.309.0 · 31 октября 2026 г.

  • Новое: GET /forms/{id}/analysis/group возвращает контакты за фильтрами анализа (период, ссылка, язык, ответ, как в GET /forms/{id}/analysis) в виде contactIds, а также withoutContact для ответов без контакта. С его помощью, как во вкладке «Действия», создают список контактов (POST /contact-lists, POST /contact-lists/{id}/members) или задачу (POST /tasks).

v1.308.0 · 31 октября 2026 г.

  • Новое: отклик по персональным ссылкам анкеты. GET /forms/{id}/follow-up возвращает для каждой ссылки контакту или потенциальному клиенту статус (submitted, started, opened, not-opened, expired), когда и сколько раз напоминали и remindBlockedBy; ссылки к карте клиента не учитываются. POST /forms/{id}/follow-up/remind с linkIds (не более 50) и templateId (шаблон сообщения для контактов) отправляет каждому шаблон с его персональной ссылкой от имени действующего лица через ту же точку отправки, что POST /contacts/{id}/conversation/email; нужно email:write. Пропускаются отправленные, истёкшие, без контакта или адреса, а также те, кому напоминали за последние 24 часа (skipped); без отправителя 422 precondition-failed с причиной no-sender.

v1.307.0 · 31 октября 2026 г.

  • Новое: взаимосвязи в ответах анкеты. GET /forms/{id}/analysis/relations проверяет каждую пару из двух вопросов (выбор, да/нет, варианты множественного выбора, названные не менее 3 раз, числа; персональные данные никогда) и, с contacts:read, признаки контакта, к которому привязан ответ (страна, метки, классы, курирующий партнёр, этап в каждой воронке, год создания; contactFeatures). Пары проверяются по ответам, в которых есть оба признака (не менее 10, группы не менее 5), точным тестом Фишера, хи-квадрат, Манна — Уитни или Краскела — Уоллиса, затем поправкой Бенджамини — Хохберга по всем парам: findings с level relationship (q меньше 0,05) или hint (меньше 0,1), не более 20, а также checked и tooSmall. С compareA и compareB также comparison: таблица сопряжённости или группы с медианой и диапазоном, уровень из той же поправки. Фильтры как в GET /forms/{id}/analysis.

v1.306.0 · 31 октября 2026 г.

  • Новое: ИИ-аналитика формы. GET /forms/{id}/analysis/ai возвращает сводку последнего запуска: утверждения с видом (counted подсчитано, classified оценка ИИ) и подтверждениями (варианты, заявки), темы свободных текстов с их заявками, предложения новых вариантов; каждое число утверждения есть в сводке фактов, остальные не выдаются (discarded). POST /forms/{id}/analysis/ai запускает анализ (202, runId), PUT /forms/{id}/analysis/ai/setting включает или выключает его для формы (администраторы; выключение удаляет сводки). В ИИ передаются вопросы, подсчитанные результаты и свободные тексты; поля имени, почтового адреса, даты рождения, адреса электронной почты и номера телефона не передаются, насколько их можно распознать как таковые (готовые поля о человеке, поля типа e-mail, телефон, интернет-адрес, собственные поля, подпись которых на это указывает). Нужно право организации на ИИ-аналитику (403 feature-not-available). Также новое в GET /forms/{id}/analysis: dataQuality с ответами на скрытые вопросы, повторными заявками и пропущенными обязательными ответами.

v1.305.0 · 31 октября 2026 г.

  • Новое: физическая активность как каталог sport языка правил, Compendium of Physical Activities 2024 (ещё не выпущено). GET /physical-activities ищет код (в том числе начало кода) или слова английского описания; каждый результат называет compendium (adult, older-adult, wheelchair), group, met с metBasis (MET, MET60, METWC, между собой несравнимы) и ссылку на источник в source. Запись — это код с ведущим нулём (01003); при сохранении и утверждении правила он должен быть загружен, иначе eintragUnbekannt. GET /standard-catalogs показывает activities (количество, компендиумы, inPlan, planRelease, источники). PATCH /standard-catalogs/sport с { inPlan } разрешает физическую активность для плана клиента или отзывает разрешение, только человек с правом «Утверждать правила», никогда автоматизация и никогда MCP (403 forbidden); в плане указаны название, длительность и частота, без значения MET. Без разрешения физическая активность учитывается в internalLeftOut.

v1.304.0 · 31 октября 2026 г.

  • Новое: МКБ-11 ВОЗ как каталог icd11 языка правил, рядом с icd10gm (ещё не выпущено). GET /diagnosis-codes принимает catalog (icd10gm по умолчанию или icd11); каждый результат теперь содержит titleDeMissing (только МКБ-11: в предварительной немецкой версии для кода ещё нет названия, тогда title — английское), titleEn и uri (только МКБ-11; код, название и URI при любой передаче идут вместе, лицензия ВОЗ). При сохранении и утверждении правила код МКБ-11 должен быть в активной версии, иначе eintragUnbekannt; в персональном плане диагноз не появляется никогда и учитывается в internalLeftOut. Изменено: GET /standard-catalogs возвращает diagnoses как список активных каталогов диагнозов (id, version, count), а не как один объект; версия 1.303.0 ещё не была выпущена.

v1.303.0 · 31 октября 2026 г.

  • Новое: продукты питания как каталог lebensmittel языка правил (ещё не выпущено). Запись — это slug продукта из GET /foods/search; при сохранении и утверждении правила он должен быть в базе, иначе eintragUnbekannt. GET /rulebook-catalogs показывает lebensmittel с записями, которые используют правила организации. GET /standard-catalogs показывает продукты (количество, inPlan, planRelease, источники) и активную ICD-10-GM; PATCH /standard-catalogs/lebensmittel с { inPlan } разрешает продукты для плана клиента или отзывает разрешение, только человек с правом «Утверждать правила», никогда автоматизация и никогда MCP (403 forbidden). Без разрешения продукты остаются внутренними и учитываются в internalLeftOut персональных планов.

v1.302.0 · 31 октября 2026 г.

  • Новое: диагнозы ICD-10-GM как каталог icd10gm языка правил (ещё не выпущено). GET /diagnosis-codes?q= ищет в активной версии код (в том числе начало, E11) или слова в названии, на немецком или русском, и возвращает код, официальное название, русское название (titleRuFrom указывает вышестоящий код, если у кода нет собственного), уровень и пригодность для кодирования; catalog с версией и указанием источника, null, пока версия не загружена. GET /rulebook-catalogs показывает icd10gm, как только версия есть; entries там называет только коды, которые используют правила организации. При сохранении и утверждении правила каждый код в empfehlung(icd10gm; <код>) должен быть в активной версии, иначе eintragUnbekannt. Диагнозы никогда не появляются в плане клиента.

v1.301.0 · 31 октября 2026 г.

  • Новое: GET /forms/{id}/responses/export, заявки формы в формате CSV. Одна строка на заявку, сначала старые: идентификатор, время (по Берлину), ссылка, язык, затем по столбцу на каждый вопрос в порядке формы. Выбор как текущая подпись (иначе подпись из заявки), числа как числа, измерения и таблицы в отдельных столбцах, повторяющаяся группа в одной ячейке, с учётом исправлений. Те же фильтры, что у GET /forms/{id}/analysis. Заголовки столбцов на языке locale; при en запятая, иначе точка с запятой и десятичная запятая; в начале BOM. Формы карты клиента только при включённых данных клиентов и clients:read.

v1.300.0 · 31 октября 2026 г.

  • Новое: GET /forms/{id}/analysis, аналитика формы с теми же цифрами, что на странице «Аналитика». По каждому вопросу база (shown: кому он был показан; для условных вопросов только при выполнении условия), подсчёт по ключу варианта, включая варианты, которых больше нет (inForm: false), свободные тексты варианта «Другое» при этом варианте (otherTexts), показатели для чисел и измерений, свободные тексты дословно; личные данные только подсчитываются (kind: personal). А также заявки по дням и языкам и dropOff, цепочка отказов из измерения формы. Фильтры from, to, link (personal, none или идентификатор публичной ссылки), language, question вместе с option. Формы карты клиента только при включённых данных клиентов и clients:read.

v1.299.0 · 30 октября 2026 г.

  • Журнал согласий (GET /consent-log): новая цель purposes.partnerAttribution (привязка к партнёру: покупка засчитывается партнёру, по рекламному коду которого пришёл посетитель). В старых записях — false. В выгрузке (GET /consent-log/export) для неё добавлен столбец «Partner-Zuordnung» после «Auf diesem Geraet angemeldet bleiben».

v1.298.0 · 30 октября 2026 г.

  • Новое: защита клиентов в рассылках. Поле clientProtection (enabled, changedAt; null без действующего модуля практики) и PUT /email-campaigns/{id}/client-protection с { enabled }, в любом статусе. Выключено: письма получателям с картой видны в общих исходящих и у контакта; уже отправленные переносятся, включение возвращает их в раздел клиентов. Выключение только при разрешённых данных клиентов, clients:read и доступе действующего лица к разделу клиентов (403 client-access-required); без модуля практики 422 practice-module-inactive.

v1.297.0 · 30 октября 2026 г.

  • GET /organization/invitations: непринятые приглашения (открытые, истёкшие, отозванные) удаляются на следующий день после истечения срока и больше не появляются, в том числе с status=EXPIRED; DELETE /organization/invitations/{id} для такого приглашения затем возвращает 404 вместо 204. Принятые приглашения сохраняются. Это указано в описании поля status.

v1.296.0 · 30 октября 2026 г.

  • Новое: происхождение (ещё не выпущено). GET /personal-plans/{id}/derivation возвращает расчёт, из которого создан персональный план, в форме POST /rulebooks/{id}/compute, а также происхождение каждого прочитанного значения (origins: дата, лабораторный отчёт); только для людей с правом «Утверждать правила», иначе 403 physicians-only. GET /care-enrollments/{id}/derivation возвращает рекомендацию, из которой начато сопровождение: свод правил, версию и правило для каждого шаблона и модуля, со следом в виде списка (уровень, значение, происхождение, дата); без этого права только свод правил и версию (physicianView: false). У планов и сопровождений, созданных раньше, происхождения нет (run или derivation пусты).

v1.295.0 · 30 октября 2026 г.

  • Новое право FORMULAR_KI (ИИ-анализ форм) в GET /organization/entitlements и в эндпоинтах лицензий. У него нет предварительных условий, оно открывает ИИ-функции анализа форм, как только они будут выпущены; цифры и диаграммы от него не зависят.

v1.294.0 · 30 октября 2026 г.

  • Изменено (решение оператора, ещё не выпущено): то, что правила говорят о человеке, читают только люди с правом «Утверждать правила». POST /rulebooks/{id}/compute и GET /rule-runs/{id} иначе отвечают 403 physicians-only (через MCP для такого человека разрешено, для автоматизации без человека никогда); GET /clients/{id}/rule-runs остаётся. Для всех остальных персональные планы приходят без rules у рекомендаций, а рекомендации, ставшие внутренними, без названия, текста и данных.

v1.293.0 · 30 октября 2026 г.

  • Персональные планы содержат только образ жизни и самочувствие (решение оператора, ещё не выпущено): собственные каталоги внутренние, пока человек с правом «Утверждать правила» не допустит их к плану (inPlan в PATCH /rulebook-catalogs/{key}, читается как inPlan и planRelease; только в областях образа жизни, other отвечает 409 area-never-in-plan). Записи содержат doctorsOnly (устанавливают только те же люди, PATCH …/entries/{entryKey}). Ни то, ни другое не через автоматизацию или MCP (403 release-needs-person). professionalOnly удалено. В планах: internalLeftOut вместо professionalOnlyLeftOut, internalEntries, lifestyleConfirmation, пробел recommendations-internal, 409 all-internal вместо professional-only; POST /personal-plans/{id}/release требует confirmLifestyle: true.

v1.292.0 · 30 октября 2026 г.

  • Изменено по сравнению с 1.291.0 (ещё не выпущено): release.waitingFor в GET /organization/license содержит английские значения (receivables, payables, subscriptions, affiliate-sales, affiliate-claims, affiliate-credit-notes, affiliate-drafts, affiliate-clawbacks, affiliate-other, иначе other). Передача организации и её отмена остаются в приложении (решение оператора), потому что в конце следует удаление.

v1.291.0 · 30 октября 2026 г.

  • Новое в GET /organization/license: для каждой организации release (идущая передача: с какого дня, только чтение до, фаза read-only или stopped, запрошена и отправлена ли резервная копия, что задерживает удаление, можно ли отменить) и releasable (можно ли её передать). Сама передача и отмена пока выполняются только в приложении.

v1.290.0 · 30 октября 2026 г.

  • Новое: изменения лицензии через API, всегда в два шага. POST /organization/license/changes/preview заранее рассчитывает изменение модуля (количество, такт): действие сразу с пропорциональным счётом или с даты смены, сумма сейчас и за период, с checksum; POST /organization/license/changes подтверждает его с этой checksum. POST /organization/license/cycle-change/preview и POST /organization/license/cycle-change переводят пакет между ежемесячным и ежегодным тактом (continue для выбираемых годовых модулей). При подтверждении заголовок Idempotency-Key обязателен (422 на headers.idempotency-key); если с предпросмотра что-то изменилось, 409 preview-outdated. Только владелец объединения; подтверждение работает и в период только чтения. Новые причины (409): no-contract, package-ending, below-usage, change-pending, contract-error; 422 на body.cycle и body.quantity.

v1.289.0 · 30 октября 2026 г.

  • Новое: лицензия организации через API (модель лицензий). GET /organization/license показывает лицензию объединения, как вкладка «Лицензия» (пакет с версией, тактом, ценой, состояние, дата смены, организации, модули, а для каждой организации выбор и уровень видео), только для владельца объединения. GET /organization/license/choices показывает места выбора, выбор и уровень видео этой организации (владелец объединения или ORG_ADMIN). PUT /organization/license/choices выбирает модули для мест выбора, PUT /organization/license/video-tier назначает забронированный уровень видео; оба только владелец объединения, свободное место действует сразу, смена — с ближайшей ежемесячной даты, и оба работают и в период только чтения. Без владельца объединения 403 forbidden с reason tenant-owner-required.

v1.288.0 · 30 октября 2026 г.

  • Новое: период только чтения модели лицензий действует и для API и API-MCP. Если лицензия организации закончилась, API 30 дней принимает только читающие вызовы, затем запись тоже заблокирована. Записывающий вызов тогда получает 403 forbidden с reason license-read-only, phase (read-only или locked) и until (последний день периода только чтения). Проходят только эндпоинты с исключением для этой фазы; сейчас в период только чтения POST /backups/runs и PUT /backups/password (резервная копия считается экспортом), а также DELETE /affiliate-coupons/{id}, PATCH /affiliate-coupons/{id} с active: false и DELETE /affiliate-tracking/webhook (завершение). После периода только чтения ни один из них не проходит. Читающие вызовы, включая POST …/validate и предпросмотры, не меняются; автоматизации организации в период только чтения продолжают работать.

v1.287.0 · 30 октября 2026 г.

  • Новое в GET /rooms/settings: recordingStorage — хранилище организации для видеозаписей онлайн-комнаты: tier (видеотариф, null без тарифа), usedBytes, limitBytes (null без лимита) и state (free, warning от 80 %, full от 100 %, unlimited). Учитываются только видеозаписи, документ которых существует; аудиозапись для сводки не учитывается. Когда хранилище заполнено, новая видеозапись не начинается, встречи продолжаются без неё. PATCH /rooms/settings по-прежнему отвечает только summary.
  • Изменённое поведение, спецификация без изменений: PATCH /organization/members/{userId} с clientAccess: true отвечает 403 forbidden с reason: practice-read-only, если практика организации доступна только для чтения (модуль завершён или период только чтения). Существующее право сохраняется, отзыв (false) возможен всегда.

v1.286.0 · 30 октября 2026 г.

  • Изменённое поведение эндпоинтов практики (своды правил и каталоги, связи и случаи расчёта, персональные планы, планы сопровождения, сопровождения и сессии, профили биомаркеров и наборы правил), спецификация не изменилась: если модуль практики организации завершён или организация находится в периоде только для чтения (модель лицензий), остаются доступны читающие эндпоинты, запрос PDF персонального плана, расчёт без сохранения (POST /rulebooks/{id}/compute) и завершение (POST /rule-cases/{id}/withdraw, DELETE /rule-connections/{id}, POST /personal-plans/{id}/withdraw, POST /care-plans/{id}/retire); раньше они отвечали feature-not-available. Записывающие эндпоинты тогда отвечают 403 forbidden с reason practice-read-only. Без практики остаётся feature-not-available.

v1.285.0 · 30 октября 2026 г.

  • Новое: PATCH /rule-connections/{id} с creditAccountId (или null) задаёт кредитный счёт партнёра у связи для расчёта, только рассчитывающая организация, только ORG_ADMIN. После этого каждое утверждение персонального плана из случая этой связи списывает с этого счёта 1 кредит (расход), отзыв плана или случая возвращает его; без счёта ничего не списывается. Неизвестный или закрытый счёт даёт 422 на body.creditAccountId (invalid_reference). GET /rule-connections теперь содержит в asComputing поле creditAccount ({ id, program, customer } или null).
  • Новое значение PERSONAL_PLAN в source кредитных проводок (GET /credits/accounts/{id}): расход и возврат из персонального плана, переданного организации-партнёру.

v1.284.0 · 30 октября 2026 г.

  • Новое в шаблонах планов сопровождения: модули. GET, POST, PUT /care-plans и POST /care-plans/validate содержат modules ([{ key, name }]), а фазы и сессии — moduleKey: части, которые попадают в сопровождение только по рекомендации. Фаза с модулем берёт с собой свои сессии; собственный модуль сессия получает только в фазе без модуля. Без указания ключ образуется из названия (строчные буквы, цифры, дефис) и сохраняется между версиями, потому что правила рекомендуют модуль по нему. Новые ошибки 422 на body.modules (too_big, required, duplicate) и на moduleKey фазы или сессии (invalid_reference).
  • Новое: варианты сессии, variants ([{ moduleKey, callGuideId, durationMinutes }], не более 5, по одному на модуль). Если модуль выбран при запуске, действуют сценарий и длительность варианта; побеждает первый выбранный. 422 на body.sessions.{n}.variants (invalid_value, required без сценария и длительности); чужой сценарий или длительность, которой нет у типа встречи, сообщаются как у сессии, на callGuideId или durationMinutes.
  • Изменено по сравнению с 1.282.0: сохранение черновика с модулями без modules или с вариантами, когда ни одна сессия не содержит variants, теперь отвечает 422 required на body.modules или body.sessions вместо 409 rejected. Пустой список modules удаляет все модули; сессия без variants теряет свои варианты, как только другая сессия указывает это поле.
  • Новое при запуске сопровождения (POST /care-enrollments): modules, ключи выбранных модулей. Части других модулей не попадают в сопровождение, сессии нумеруются заново; без указания ни одного. Рекомендованные называет GET /clients/{id}/care-plan-suggestions. 422 на body.modules: invalid_reference для ключа, который не относится к версии, too_small, если осталось бы меньше двух сессий. Копия copy содержит modules (выбранные) и moduleKey у фаз и сессий, а у сессий ещё variantModuleKey (модуль, вариант которого действует); самих вариантов в ней нет.

v1.283.0 · 30 октября 2026 г.

  • Новое в GET /rule-cases: retainUntil, окончание срока хранения случая у рассчитывающей организации: десять лет после последнего события (расчёт или отзыв), как у карты (§ 630f абз. 3 ГГУ Германии). Автоматически ничего не удаляется.

v1.282.0 · 30 октября 2026 г.

  • Изменённое поведение POST /care-plans и PUT /care-plans/{id} (спецификация не изменилась): если в черновике есть модули или варианты сеансов (созданные в приложении), сохранение без них отклоняется с 409 conflict и reason rejected, вместо того чтобы молча их удалить. Модули и варианты в эндпоинтах шаблонов появятся в одной из следующих версий; предложения содержат их с 1.281.0 (modules).

v1.281.0 · 30 октября 2026 г.

  • Новое в GET /clients/{id}/care-plan-suggestions: whole (рекомендован ли весь шаблон) и modules, рекомендованные модули шаблона с key, name и sources. Модуль — часть шаблона (фазы или сеансы), которая попадает в сопровождение только по рекомендации; шаблон появляется и тогда, когда рекомендован только модуль в нём.

v1.280.0 · 29 октября 2026 г.

  • Новое: оценки подсказок из расчётов других организаций возвращаются рассчитывающей организации, с причиной и названием партнёрской организации, без имени человека; не при отозванной связи или отозванном случае. PUT /care-sessions/{id}/foreign-hints/{runId}/{rule} отвечает с sent, foreignHints содержат judgementSent. В рассчитывающей организации GET /rulebooks/{id}/hint-stats учитывает их (accurate/notAccurate по всем, fromPartners доля партнёров); новое GET /rulebooks/{id}/hint-objections (данные клиентов, clients:read): последние возражения по каждому правилу с причиной, by и fromPartner.

v1.279.0 · 29 октября 2026 г.

  • Новое: подсказки из расчётов других организаций в кокпите. GET /care-sessions/{id}/hints возвращает foreignHints: для каждой рассчитывающей организации и набора правил последний действующий расчёт в карте, с runId, computedBy, rulebook, versionNumber, approvedBy, computedAt, reportId и теми же полями, что и hints. PUT /care-sessions/{id}/foreign-hints/{runId}/{rule} сохраняет оценку (judgement, reason, runHash; только человек, никогда автоматизация или MCP, 403 judgement-needs-person; отозванный расчёт: 409 conflict с reason run-withdrawn). Оценка остаётся в собственной организации.

v1.278.0 · 29 октября 2026 г.

  • Новое: PDF персонального плана. POST /personal-plans/{id}/pdf запрашивает его (202; только для утверждённых или отозванных планов, черновик: 409 conflict с reason not-released), GET /personal-plans/{id}/pdf показывает состояние (status: none, pending, ready, failed, а также documentId); готовый с подписанной ссылкой (url, filename, expiresAt, действует несколько минут). Для каждого состояния плана создаётся один PDF; после отзыва состояние none, новый содержит отметку. Данные клиентов, журнал доступа.

v1.277.0 · 29 октября 2026 г.

  • Новое: персональные планы по случаю партнёрской организации (расчёт за пределами организации, /rule-cases). GET /rule-cases/{id}/personal-plans выводит их список, POST /rule-cases/{id}/personal-plans создаёт черновик по результату, сохранённому в случае (language, title); отозванный случай: 409 conflict с reason case-withdrawn. Через POST /personal-plans/{id}/release неизменяемая копия передаётся в карту у партнёра; если карты там нет: 409 partner-record-missing.
  • Новое в планах: fromOrganization (копия из другой организации, её название; иначе null), fromCase (создан по случаю) и в отдельном плане delivered (передан партнёру). POST /personal-plans/{id}/withdraw отзывает и переданную копию; копию отзывает только источник (409 foreign-plan). Если рассчитывающая организация отзывает случай (POST /rule-cases/{id}/withdraw), его планы тоже перестают действовать.

v1.276.0 · 29 октября 2026 г.

  • Новое: персональные планы (данные клиентов, biomarkers:* и clients:*, журнал доступа). POST /clients/{id}/personal-plans рассчитывает действующую версию набора правил (rulebookId, необязательно reportId) и создаёт черновик с рекомендациями из собственных каталогов и их текстами (409 no-recommendation, professional-only); GET /clients/{id}/personal-plans, GET/PATCH/DELETE /personal-plans/{id} (название, coverNote, remove, texts; только черновик, 409 not-draft). POST /personal-plans/{id}/release и …/withdraw только человеком с правом «Утверждать правила», никогда автоматизацией или через MCP (403 release-needs-person, approve-right-missing); утверждение только без пробелов (409 plan-incomplete с gaps). Указание организации: GET/PATCH /personal-plan-settings (задаётся как утверждение).
  • Новое в собственных каталогах: professionalOnly (только для специалистов) в GET/POST/PATCH /rulebook-catalogs…; записи таких каталогов никогда не появляются в персональном плане.

v1.275.0 · 29 октября 2026 г.

  • Новое: собственные каталоги рекомендаций с текстами. POST /rulebook-catalogs создаёт каталог (names, area: nutrition, exercise, sleep, mental, supplements, other; ключ создаётся из первого названия и не меняется), GET /rulebook-catalogs/{key} читает его со всеми записями и текстами, PATCH /rulebook-catalogs/{key} меняет названия, область, порядок или archived. Записи: POST /rulebook-catalogs/{key}/entries (names, texts на каждом языке в HTML, очищается при сохранении) и PATCH /rulebook-catalogs/{key}/entries/{entryKey}. Название может встречаться в каталоге только один раз (422 duplicate в body.names); слишком много каталогов или записей 409 too-many.
  • Изменено: GET /rulebook-catalogs наряду с каталогом путей перечисляет собственные каталоги, не находящиеся в архиве (без архивных записей). Правило рекомендует запись так же, как путь; название из нескольких слов может стоять в формуле и без кавычек (рекомендация(Сон; спокойное дыхание)).

v1.274.0 · 29 октября 2026 г.

  • GET /clients/{id}/care-plan-suggestions теперь включает и пути из расчётов других организаций (rule-runs, последний для каждой рассчитывающей организации и набора правил), если вы приняли их план сопровождения: предлагается ваша собственная копия. Новое для каждого источника: computedBy (название рассчитывающей организации, иначе null); rulebookId у таких источников равен null. Планы сопровождения принимаются только в интерфейсе.

v1.273.0 · 29 октября 2026 г.

  • Новое: расчёт за пределами организации. GET /rule-connections, POST /rule-connections (создать связь со своими наборами правил, код rech_… возвращается один раз и действует семь дней), POST /rule-connections/redeem (активировать код другой организации, legalBasisConfirmed: true подтверждает правовое основание) и DELETE /rule-connections/{id}. Создание, активация и отзыв только ORG_ADMIN; создание и активация только человеком, никогда автоматизацией и никогда через MCP (403 forbidden с reason connection-needs-person).
  • Новое: POST /clients/{id}/rule-runs поручает расчёт другой организации через активную связь: передаются только значения, которые читает действующая версия набора правил, а также имя, дата рождения, возраст и пол; никогда из автоматизации (403 request-needs-person). Обратно приходит расчёт без формул: GET /clients/{id}/rule-runs, GET /rule-runs/{id} (объект результата как в compute, правила с названиями, единицей, группами и подсказкой). Рассчитывающая организация видит свои случаи в GET /rule-cases и отзывает случай через POST /rule-cases/{id}/withdraw (право «Утверждать правила», только человек); расчёт у партнёра тогда получает status: withdrawn.

v1.272.0 · 29 октября 2026 г.

  • GET /rulebook-sources теперь перечисляет и таблицы и повторяющиеся группы анкет карты: для каждой ячейки таблицы anamnese:<блок>.<строка>.<столбец> (при одном столбце anamnese:<блок>.<строка>), для каждого столбца выбора повторяющейся группы множество anamnese:<блок>.<столбец> по всем строкам и anamnese:<блок>.anzahl. POST /rulebooks/{id}/compute берёт их из последней отправки, ответившей на блок, с исправлениями.
  • Новое: GET /rulebook-catalogs с каталогами, из которых правила дают рекомендации, сегодня каталог путей (weg: шаблоны планов сопровождения, ключ первая версия шаблона). Новое: GET /clients/{id}/care-plan-suggestions (careplans:read и clients:read, данные клиентов, журнал доступа) с путями, которые утверждённые наборы правил предлагают клиенту, с правилами и последней опубликованной версией (plan). Предложение ничего не запускает; запуск через POST /care-enrollments.

v1.271.0 · 29 октября 2026 г.

  • Подсказки в кокпите: каждое правило в ответах под /rulebooks содержит hint ({ color, action } с color red, gold или grey, иначе null). При сохранении (PUT /rulebooks/{id}/draft/rules/{key}, POST /rulebooks/{id}/draft/validate) hint задаёт подсказку, null убирает её, без указания она сохраняется. Подсказкой может быть только правило, которое даёт «да» или «нет» (422 на body.hint); подсказка входит в контрольную сумму. Новое: GET /rulebooks/{id}/hint-stats с оценками коучей по каждому правилу (accurate, notAccurate).
  • Новое в careplans: GET /care-plans/{id}/rulebooks, POST /care-plans/{id}/rulebooks (привязать набор правил, только в черновике собственного шаблона, иначе 409 plan-not-editable), PATCH /care-plans/{id}/rulebooks/{rulebookId} (active, всегда) и DELETE /care-plans/{id}/rulebooks/{rulebookId}. GET /care-sessions/{id}/hints возвращает подсказки сессии (красные, золотые, серые, state applies или cannot-assess с missing, оценка, runHash; clients:read, журнал доступа). PUT /care-sessions/{id}/hints/{versionId}/{rule} сохраняет оценку (accurate или not-accurate с reason), только человеком: никогда автоматизацией и никогда ИИ-агентом через MCP (403 forbidden с reason judgement-needs-person).

v1.270.0 · 29 октября 2026 г.

  • GET /rulebook-sources теперь, помимо лабораторных показателей и данных о человеке, перечисляет анамнез из полей карты (anamnese:<ключ поля>, для измерений из нескольких частей anamnese:<ключ>.<часть>) и состояние сопровождения (plan:sitzung, plan:tag, plan:phase). Правила могут их читать. POST /rulebooks/{id}/compute учитывает анамнез; состояние сопровождения ему неизвестно, так как он считает без сессии: правила, которым оно нужно, дают «неизвестно» (unknown).
  • Изменено: callMinutes в GET /affiliates/activity теперь учитывает только длительность разговоров: звонки с готовой заметкой о разговоре, которая фиксирует не только голосовую почту, или со сценарием и результатом, а также принятые звонки без заметки от 30 секунд, которые не являются голосовой почтой. Раньше учитывалась длительность каждого принятого звонка, включая голосовую почту, поэтому значения могут быть меньше. calls не изменился.
  • Изменено: PATCH /organization отклоняет смену type на BUSINESS или HOLDING с 409 conflict и reason: organization-limit, если в лицензионном пакете нет свободного места для ещё одной коммерческой организации или холдинга. Это касается только пакетов с заданным числом организаций; действующие лицензии без такого числа не затронуты.

v1.269.0 · 29 октября 2026 г.

  • Новое: наборы правил языка правил под /rulebooks (biomarkers:read, biomarkers:write), те же, что в разделе «Правила» приложения. Чтение и ведение: GET /rulebooks, GET /rulebooks/{id} (с ?version= определённая версия), POST /rulebooks, PATCH /rulebooks/{id}, DELETE /rulebooks/{id} и GET /rulebook-sources (что могут читать правила: лабораторные показатели и данные о человеке, с названиями и единицами). Правила в черновике: PUT /rulebooks/{id}/draft/rules/{key} формулой (formula, на языке запроса, как в строке формулы) или деревом (expression), POST /rulebooks/{id}/draft/validate как пробный прогон и DELETE /rulebooks/{id}/draft/rules/{key}. Каждое правило возвращается формулой на трёх языках и деревом. Версии: POST /rulebooks/{id}/versions (черновик как копия действующей), DELETE /rulebooks/{id}/draft и POST /rulebooks/{id}/draft/approve.
  • Утверждать (POST /rulebooks/{id}/draft/approve) может только пользователь с правом организации «Правила» (иначе 403 forbidden с reason approve-right-missing), никогда автоматизация и никогда ИИ-агент через MCP (403 forbidden с reason approve-needs-person): утверждение является решением врача. Версия с ошибками отвечает 422, версия без правил 409 version-empty. При утверждении сохраняется контрольная сумма правил (checksum).
  • Новое: POST /rulebooks/{id}/compute с { clientId, rules? } (biomarkers:read и clients:read, а также включённые данные клиентов; обращение записывается в журнал доступа) считает действующую версию по утверждённым лабораторным показателям клиента и возвращает объект результата: values, inputs, groups, trace, версию с checksum и утверждением, а также hash. Без утверждённой версии 409 no-effective-version; если правила больше не совпадают с контрольной суммой, 409 checksum-mismatch, и расчёт не выполняется.
  • Устарело: восемь эндпоинтов под /biomarker-rule-sets (biomarkers.listRuleSets, getRuleSet, createRuleSet, validateRules, replaceRules, deleteRuleSet, confirmRuleSet, unconfirmRuleSet). Они продолжают отвечать до 31.12.2026 с заголовками Deprecation и Sunset, после чего будут удалены. В API MCP они скрыты начиная с этой версии. Их наборы правил не переносятся; создавайте правила под /rulebooks.

v1.268.0 · 27 октября 2026 г.

  • Исправлено: POST /email-campaigns/{id}/report/fetch-reasons теперь сопоставляет и возвраты, о которых SendGrid сообщает в ту же секунду, что и отправка (например, немедленные отказы Gmail). SendGrid хранит время в списках блокировки с точностью до секунды; такие записи считались более ранними, чем отправка, и учитывались в withoutEntry.

v1.267.0 · 27 октября 2026 г.

  • Изменено: после Bounces и Blocks POST /email-campaigns/{id}/report/fetch-reasons читает также список Invalid Emails в SendGrid, но только для возвратов, у которых ещё нет причины и нет записи в Bounces; найденная запись сохраняется как возврат (type bounce, source suppression-list). Новое в ответе: read.invalidEmails. Ограниченному ключу для этого нужно право suppression.invalid_emails.read; если права нет или SendGrid возвращает ошибку, read.invalidEmails равно null (вместо 0 для «прочитано, пусто» или «не требовалось»), причины из Bounces и Blocks сохраняются, а эти письма учитываются в withoutEntry.

v1.266.0 · 27 октября 2026 г.

  • Новое: основные настройки каталога GET /finder/settings (finder:read: enabled, brandId, taxonomyCount) и PATCH /finder/settings (finder:write, тело { brandId }, null означает стандартный борд организации). Изменять могут только администраторы организации (иначе 403 forbidden); если каталог не включён, 403 feature-not-available; борд, которого нет в организации, даёт 422 validation-failed с invalid_reference в body.brandId. Борды возвращает GET /sites/brands. Новое право finder:write: расширьте свои ключи, если хотите менять эту настройку.

v1.265.0 · 27 октября 2026 г.

  • Новое: объединение контактов POST /contacts/{id}/merge (contacts:write). Контакт из пути остаётся, контакты из mergeContactIds (от 1 до 20, того же типа) переносятся на него со всеми ссылками и удаляются; окончательно. fieldSources указывает для каждого поля идентификатор участника, чьё значение применяется; теги объединяются. Ответ { contact, mergedContactIds, reassignedReferences }. 409 с reason type-mismatch, bookings-on-multiple или отдельной причиной для каждой блокировки (client-records-on-multiple, practitioner-profiles-on-multiple, sales-profiles-on-multiple, company-profiles-on-multiple, marketplace-subscriptions-on-multiple, calendars-on-multiple). Тот же порядок действий, что и в приложении.
  • Новое: событие contacts.contact.merged, один раз на каждое объединение, в том числе из приложения, с оставшимся контактом (contact, в той же форме, что и в contacts.contact.updated), mergedContactIds и reassignedReferences. Для удалённых контактов не приходит contacts.contact.deleted, для оставшегося не приходит contacts.contact.updated: перенесите свои записи с удалённых идентификаторов на оставшийся контакт. Раньше объединение не отправляло событий.
  • Изменено: оба ответа 409 у DELETE /contacts/{id} (in-use, client-record-retained) указывают в detail путь POST /contacts/{id}/merge.
  • Изменено: contacts.contact.created теперь приходит и для специалистов, которых Longevity-Finder создаёт при проверке сертификата, и для профилей, переносимых по одному из другого каталога. Теперь событие создаёт каждый новый контакт, каким бы путём он ни появился; исключение по-прежнему составляют массовые импорты и массовые переносы (1.263.0), а также тестовые случаи, которые claritos передаёт в организацию для тренировки.

v1.264.0 · 27 октября 2026 г.

  • Новое: отчёт по кампании GET /email-campaigns/{id}/report с доставкой, причинами возвратов (SMTP-код, категория SendGrid, ответ сервера без адресов электронной почты), партиями, провайдерами, доменами, последствиями (список блокировки, отзывы без отмены согласий импорта), ответами, переходами по ссылкам, открытиями и записями на приём; а также остановка с сообщением SendGrid (run.providerMessage, run.haltMeaning). Обращения, которые, вероятно, были не от человека (фильтры безопасности, предварительные загрузки), считаются отдельно (botClicks, prefetches).
  • Новое: GET /email-campaigns/{id}/recipients (постранично через курсор, фильтры group, batch, domain, provider, reasonType, smtpCode, reasonCategory, search, updatedSince) и GET /email-campaigns/{id}/recipients/{recipientId} с историей всех сообщений, блокировкой, согласием, ответами (только переписка, время и тональность), переходами, открытиями и записями (appointmentId, appointmentTypeId, appointmentTypeName на основном языке организации, status как в GET /appointments). Оба дополнительно требуют contacts:read.
  • Новое: POST /email-campaigns/{id}/report/fetch-reasons получает причины возвратов из списков блокировки SendGrid (в SendGrid ничего не меняется; можно повторять); 409 с причиной sendgrid-suppression-forbidden, если ключу нельзя читать списки. Новое: GET/PUT /email-campaigns/tracking с clicksPerPerson (переходы по каждому человеку или только по ссылкам, настройка организации; изменять могут только администраторы).
  • Новое: события campaigns.email.clicked и campaigns.email.opened, только для обращений, которые, вероятно, исходили от человека; отправляются примерно через восемь секунд после обращения, чтобы фильтр безопасности, открывающий все ссылки письма сразу, был распознан заранее. occurrence равно first при первом переходе получателя по этой ссылке или его первом открытии, иначе repeat. contactId, recipientId и occurrence указываются, только если организация считает переходы по каждому человеку (иначе null); если она считает только по ссылкам, claritos отсеивает программы без браузера, слишком ранние обращения и HEAD, но не серии, так как обращения не привязаны к человеку. Оба являются триггерами автоматизаций с фильтром по кампании и по occurrence. Изменено: у кампаний есть поле measureOpens (измерять открытия собственным изображением, по умолчанию выключено), доступное для чтения и задаваемое при создании и изменении.

v1.263.0 · 27 октября 2026 г.

  • Изменено: contacts.contact.created теперь приходит и при этих новых контактах: новый покупатель из checkout (в том числе при оформлении лицензии), в партнёрской программе (одобрение заявки, closer-сервис, команда в партнёрском портале, ещё одно лицо из формы заявки, перенесённый потенциальный клиент), контактное лицо, перенесённое из письма, новый деловой партнёр при создании документа учёта и родственники, которых клиент добавляет в портале. Если у нового контакта есть теги, для каждого тега приходит contacts.tag.added, как при POST /contacts. Если используется существующий контакт, события нет.
  • Изменено: массовые переносы больше не отправляют события, ни contacts.contact.created, ни contacts.tag.added: перенос клиентов Stripe, основных данных DATEV и списка партнёров портала в бухгалтерии, а также импорт основных данных кредитов, в том числе через POST /credits/import-profiles/{id}/master-data. Раньше на каждый новый контакт приходило событие, а один запуск часто создаёт сотни. Это касается и контактного лица, которое создаёт такой перенос, когда лицо с номером НДС становится компанией. Если же claritos так разделяет уже существующий контакт (сопоставление с DATEV, изменённый номер НДС в списке партнёров, упорядочивание индивидуальных предпринимателей, форма контакта), для нового контактного лица по-прежнему приходит contacts.contact.created. Если эти контакты нужны, прочитайте их после запуска через GET /contacts.

v1.262.0 · 27 октября 2026 г.

  • Изменено: contacts.contact.created теперь приходит и тогда, когда форма создаёт новый контакт: отправки по ссылке формы (/f/…), через форму воронки или POST /forms/{id}/responses, персональная ссылка (POST /forms/{id}/personal-links), а также профили компаний и продавцов. Раньше событие приходило только для контактов, созданных вручную, через POST /contacts и из документов. Если форма находит существующий контакт, события нет. Правило: каждый новый контакт создаёт событие, массовый импорт не создаёт; другие пути создания последуют и будут перечислены здесь.

v1.261.0 · 27 октября 2026 г.

  • Новое: логотип лицензии формы в два шага, POST /forms/{id}/license-logo/upload (подписанный адрес) и POST /forms/{id}/license-logo/confirm (только после этого форма показывает логотип; если файла ещё нет: 422 в body.storageKey), удаление через DELETE /forms/{id}/license-logo; GET /forms/{id} содержит licenseLogoUrl. POST /forms/{id}/personal-links создаёт или находит контакт по данным человека (values с полями std:, необязательно documentId) и возвращает заполненную ссылку на семь дней (url, contactId, validUntil; 201, нужны forms:write и contacts:write). Новая причина target-not-supported (409) для форм, цель которых не поддерживает персональную ссылку. Архивные формы: 409 archived для всех четырёх.

v1.260.0 · 27 октября 2026 г.

  • Новое: PATCH /forms/{id} меняет настройки формы как конструктор (название, обращение, публичная ссылка, портал, consentMode, отображение, поиск адреса, указание лицензии, завершение); краткое имя, цель, страницы и согласия по-прежнему задаёт PUT (при передаче ответ 422 invalid_combination); архивная форма даёт 409 archived. GET /forms/{id}/share-link читает, POST /forms/{id}/share-link создаёт ссылку организации для распространения (повторяемо; новая причина public-access-disabled, 409). GET /forms/{id} и ответы POST /forms, PUT /forms/{id} и вставки шаблона содержат настройки: showProgress, showSummary, showFieldLabels, showClientHeader, reminderService, recognitionCard, translateResponses, thirdPartyMode, addressFinderMode, addressFinderPlaceholder, licenseLabel, completion. Изменено: publicUrl в GET /forms и GET /forms/{id} теперь только ссылка организации; раньше там могла стоять партнёрская ссылка, через которую каждая отправка приписывалась этому партнёру. Без ссылки организации там null.

v1.259.0 · 26 октября 2026 г.

  • Новые события contacts.websiteAnalysis.completed и contacts.websiteAnalysis.failed, ровно один раз на каждый запуск анализа веб-сайта, в том числе из портала, сценариев разговора, встреч и API. Полезная нагрузка websiteAnalysis содержит только идентификаторы и состояние: contactId (запрошенный), targetContactId (с результатом), topicId, topicName, language, source (app, portal, callGuide, meeting, api), userId, partnerContactId, affiliateId, startedAt, finishedAt; для completed также pagesRead и unverifiedQuotes, для failed — фиксированная причина reason, как failure.reason в GET. Без текста страниц и результата: результат даёт GET /contacts/{id}/website-analysis. В автоматизациях доступны как триггеры с фильтрами по источнику и причине.

v1.258.2 · 26 октября 2026 г.

  • Изменено: у анализа веб-сайта больше нет переключателя включения. Поле enabled убрано из ответов GET/POST/PUT /contacts/{id}/website-analysis и GET/PUT /website-analysis/settings, запуск больше не отвечает 403 feature-not-available. Версии 1.258.0 и 1.258.1 никогда не были в production.

v1.258.1 · 26 октября 2026 г.

  • Изменено: POST /contacts/{id}/website-analysis без language использует язык организации (если de, en или ru, иначе de) и отвечает 403 feature-not-available раньше любых других проверок, пока функция не включена в среде.

v1.258.0 · 26 октября 2026 г.

  • Новое: анализ веб-сайта у контакта. GET /contacts/{id}/website-analysis (contacts.getWebsiteAnalysis) возвращает поводы для разговора с веб-сайта контакта (current в виде HTML с прочитанными страницами, running, failure, history, dailyLimit); у интересента партнёра результат хранится у контакта-компании (targetContactId). POST (contacts.startWebsiteAnalysis, 202) запускает анализ с topicId и language, PUT (contacts.updateWebsiteAnalysis) сохраняет версию вручную; оба только с действующим пользователем. Ошибки: 422 precondition-failed с reason: no-website или daily-limit-reached, 409 analysis-running, 403 feature-not-available, пока функция не включена в среде.
  • Новое: GET/PUT /website-analysis/topics (contacts.listWebsiteTopics, contacts.setWebsiteTopics) читает и заменяет промпты тем организации или, с campaignId, партнёрской кампании (name, prompt, isDefault, не более 20, одна тема по умолчанию). GET/PUT /website-analysis/settings (contacts.getWebsiteAnalysisSettings, contacts.setWebsiteAnalysisSettings) читает и задаёт дневной лимит (dailyLimit от 0 до 500). Изменения только ORG_ADMIN.

v1.257.0 · 26 октября 2026 г.

  • Сценарии разговора: nextCallGuideId у пунктов и ответов в content /call-guides (чтение и запись), «Продолжить сценарием …». Выход тогда становится концом: проход завершается своим результатом, а целевой сценарий начинается в том же разговоре. next, отличный от null, рядом с ним даёт 422 invalid_combination у этого выхода; цель, не являющаяся активным сценарием организации, даёт 422 sprung-ziel-unbekannt.
  • Событие callguides.run.completed: guideRun.previousRunId (проход, из которого перешли сюда через «Продолжить сценарием …», иначе null) и guideRun.nextGuideId (целевой сценарий, если проход завершается переходом, иначе null).

v1.256.0 · 26 октября 2026 г.

  • Свои поля: GET /organization/custom-fields (с папками), POST /organization/custom-fields, PATCH /organization/custom-fields/{id}, POST /organization/custom-fields/{id}/archive и /unarchive. Чтение с organization:read, запись с organization:write и ORG_ADMIN. Краткое имя, тип и сущности после создания не меняются (422 immutable); варианты имеют постоянный key, переименование по ключу не затрагивает сохранённые значения. Новые причины custom-field-slug-taken и system-field (обе 409).

v1.255.0 · 26 октября 2026 г.

  • Пайплайны (PI.37): у этапов есть partnerRights (view, moveIn, moveOut, edit, delete), чтение и запись через эндпоинты этапов (только целиком; без view других прав нет). Для этапа закрытия moveIn означает закрыть, а moveOut — вернуть в работу. partnerVisibility остаётся для чтения (выводится из прав) и записи (переводится в права, delete никогда); partnerRights имеет приоритет.

v1.254.0 · 26 октября 2026 г.

  • Пайплайны (PI.31, список звонков): callList.businessOnly (только предприниматели и фрилансеры, B2B; дайлер в этом пайплайне никогда не спрашивает о согласии, отзыв по-прежнему блокирует), запись через PATCH /pipelines/{id}. Каждое изменение записывается; callList.businessOnlyChange показывает последнее (at, via, userId, только чтение).

v1.253.0 · 26 октября 2026 г.

  • Пайплайны (PI.28, список звонков): у этапов есть onCallList (карточки открытого этапа в списке звонков), у пайплайнов callList с busy (followUp с busyFollowUpMinutes или end), noAnswerRetryMinutes, ringSeconds, hours (days 1–7, from, to) и firstCallStageId; запись через PATCH /pipelines/{id} (callList, частично) и на этапах (onCallList). Сам список обзванивает дозвонщик в портале или CRM.

v1.252.0 · 25 октября 2026 г.

  • Пайплайны (PI.27): новый GET /pipelines/lead-quality (from, to, необязательно pipelineId): записи пайплайнов продаж, созданные за период, по источникам (kind form/funnel/existing с sourceId и name, иначе via) и по кампаниям (utmCampaign, utmSource) с leads, open, parked, won, lost, unqualified и долями unqualifiedShare, wonShare (от 0 до 1 от всех лидов группы).

v1.251.0 · 25 октября 2026 г.

  • Пайплайны (PI.26): у записей есть leadSource (form, funnel или existing для существующих интересантов, с sourceId и utm из визита в воронку: source, medium, campaign), для новых записей с этого момента. Новые GET/POST /pipelines/{id}/backfill: перенос для обязательного пайплайна, интересанты допущенных партнёров без открытой или отложенной записи попадают на первый этап (running/finished/failed, candidates, created, failed); запускается и сам при включении couplings.prospectsRequired. Без обязательности precondition-failed (prospects-not-required), во время переноса conflict.

v1.250.0 · 25 октября 2026 г.

  • Сценарии разговора (Телефония TW.48b): notReached[].cardStatusEvent принимает absence (автоответ об отсутствии); шаблон ситуаций задаёт его для ситуации отсутствия. Значения следуют триггерам статуса карточки пайплайнов (PI.22b).

v1.249.0 · 25 октября 2026 г.

  • Пайплайны (PI.22b): новый триггер статуса карточки absence (звонок: сообщение об отсутствии) наряду с busy, noAnswer, voicemail и invalidNumber: у статусов карточки (trigger), в событии pipelines.entry.cardStatusChanged и как situation в POST /pipelines/entries/{id}/outcome (одна попытка, без смены этапа).

v1.248.0 · 25 октября 2026 г.

  • Пайплайны, процесс продаж (PI.25): этапы указывают appointmentTypeIds (типы встреч) и role (preSetter, setter, closer). Когда встреча указанного типа для контакта открытой записи бронируется, переносится, отменяется или пропускается, статус карточки следует за ней; при бронировании ведущий становится ответственным и получает роль этапа, а прежний ответственный — предыдущую роль. Новый вид требования appointment с appointmentTypeId (null = любой тип). У записей есть bookedAppointmentTypeIds и roles (человек, имя, встреча). Чужой тип встречи даёт invalid_reference.

v1.247.0 · 25 октября 2026 г.

  • Сценарии разговора (/call-guides, чтение и запись): content.results[].pipelineEffect с pipelineId, stageId, reasonId, packageId, cardStatusId это действие результата в пайплайне при завершении. content.notReached[].cardStatusEvent (busy, noAnswer, voicemail, invalidNumber, те же значения, что и trigger в pipelines.entry.cardStatusChanged) это событие, с которым ситуация задаёт статус карточки. До сих пор API не показывал ни того, ни другого, и PATCH с content их терял.

v1.246.0 · 25 октября 2026 г.

  • Пайплайны, процесс продаж (PI.24): POST /pipelines/entries/{id}/outcome записывает результат на карточке: статус карточки, этап с причиной (те же требования, что и moveEntry), пакет и повторный контакт одним вызовом, или notReached с situation (busy, noAnswer, voicemail, invalidNumber): одна попытка, никогда смена этапа. У записей есть attemptsInStage и lastAttemptAt (каждое перемещение обнуляет попытки). Новый путь guide в via (результат сценария) в истории и в pipelines.entry.stageChanged/cardStatusChanged.

v1.245.0 · 25 октября 2026 г.

  • Новое: GET /contacts/{id}/phone-consent и PUT /contacts/{id}/phone-consent (contacts.getPhoneConsent, contacts.setPhoneConsent): согласие контакта на телефонные звонки, отдельно от эл. почты и SMS. Ответ с state (granted, revoked, none), since, number, callable (yes звонить: компания или задокументированное согласие; ask сначала спросить: потребитель без согласия; no не звонить: отозвано, в том числе у компаний) и history с reason и by (userId или contactId, name). PUT принимает granted, reason (обязательно, не более 2000 символов) и необязательно number, только с действующим пользователем (no-acting-user); не участник получает 403.
  • Новое: GET /contacts/{id}/reminder-service (contacts.getReminderService) и POST /contacts/{id}/reminder-service/unsubscribe (contacts.unsubscribeReminders): может ли контакт получать напоминания о встречах по эл. почте и SMS (email, sms, у каждого state, value, since), и отписка от обоих каналов, повторяемо, только с действующим пользователем — участником организации.

v1.244.0 · 25 октября 2026 г.

  • Автоматизации: у триггера pipelines.entry.cardStatusChanged есть фильтр «Статус карточки: один из», в каталоге (GET /automation-catalog) как путь toCardStatus.id с kind pipelineCardStatus. Он сохраняется как pipelineStage, списком идентификаторов (новый статус карточки); идентификаторы, не принадлежащие организации или выбранным пайплайнам, при сохранении отклоняются.

v1.243.0 · 25 октября 2026 г.

  • Сценарии разговора: (1) callguides.run.completed теперь приходит при первом явном завершении прохода («Завершить разговор») с результатом, который выбрал человек (resultId/resultName), а не само собой, как только основной путь дошёл до конца; по-прежнему один раз за проход, повторное открытие и завершение ничего не сообщают. (2) Новое content.notReached в /call-guides (чтение и запись): ситуации «Не дозвонились» с id, name и suggestion (hours, businessDays, manual, none). Завершение с такой ситуацией не отправляет callguides.run.completed, последующее завершение с результатом отправляет один раз. До сих пор API не показывал этот список, и PATCH с content его терял. (3) Действие оплаты может содержать links: []: тогда действует только ссылка на оплату записи пайплайна; если она есть у записи, она важнее собственных ссылок действия. Действие оплаты теперь неполное только без templateId.

v1.242.0 · 25 октября 2026 г.

  • Обратная связь SendGrid (SV.198): POST /sendgrid/events теперь создаёт только ОДИН вебхук на аккаунт SendGrid. Если в аккаунте уже есть вебхук claritos (например, от другой организации на том же аккаунте), подключение использует его; остальные объединяются. Новые причины в 422 precondition-failed: sendgrid-webhook-limit (тариф SendGrid не позволяет ещё один вебхук) и sendgrid-webhook-forbidden (SendGrid отклонил ключ для вебхуков); раньше обе приходили как sendgrid-events-failed, которая теперь содержит причину от SendGrid в detail. checkError теперь может быть sendgridVerbindung.fehler.ereignisseTarif или sendgridVerbindung.fehler.ereignisseRecht. События получает только организация, к письму которой они относятся: возвраты другой организации на том же аккаунте больше не блокируют адрес.

v1.241.0 · 25 октября 2026 г.

  • Пайплайны, процесс продаж (PI.23): пакеты. У пайплайнов есть packages (название, товар, ссылка на оплату, default), PUT /pipelines/{id}/packages сохраняет весь список (не более одного по умолчанию, отсутствующие архивируются, только администраторы организации). У записей есть packageId, packageName и checkoutLinkId; packageId задаётся в POST /pipelines/entries, PATCH /pipelines/entries/{id} и moveEntry (товар и сумма нетто из пакета, если в том же вызове нет valueCents). Новый вид требования package (путь body.packageId). Пакет по умолчанию сам к новым записям не записывается.
  • Пайплайны, поддержка (PI.19b): утверждённый кредит SLA передаётся в выставление счетов и появляется как «скидка» в следующем счёте по подписке или следующем черновике. Новый slaCredit.status scheduled с scheduledAt; если передача не удалась, остаётся released с handoverError, и POST …/sla-credit/release пробует снова.

v1.240.0 · 23 октября 2026 г.

  • Пайплайны, процесс продаж (PI.22): статус карточки, текущее положение дел на карточке независимо от этапа. У пайплайнов есть cardStatuses (название, цвет, порядок, trigger), у записей cardStatus и cardStatusSince. Новое: PUT /pipelines/{id}/card-statuses сохраняет весь список (отсутствующие архивируются, только администраторы организации), GET /pipelines/{id}/card-statuses/report возвращает число открытых записей и время по этапу и статусу карточки, а также смены за период. PATCH /pipelines/entries/{id} задаёт cardStatusId (null = без статуса), GET /pipelines/entries фильтрует по cardStatusId (none = без статуса). Новое событие pipelines.entry.cardStatusChanged с fromCardStatus, toCardStatus, trigger и via; создание его не отправляет, created уже содержит статус.

v1.239.0 · 23 октября 2026 г.

  • Новое: POST /invoices/{id}/collect сразу списывает оплату по открытому счёту подписки с карты или по мандату прямого дебета, не дожидаясь ежедневного запуска. Ответ result: charged (карта списана, подтверждение через вебхук) или submitted (прямой дебет отправлен, оплачено после поступления денег). 409 с reason not-collectable, skipped или collection-failed.

v1.238.0 · 23 октября 2026 г.

  • Новое: завершение сессии сопровождения (практика BP.3a). POST /care-sessions/{id}/complete завершает сессию и её сценарий за один шаг: сначала прохождение с guide.outcomeId (обязателен, если у сценария есть результаты) и guide.reasons (обоснование для каждого незакрытого обязательного шага; если его нет, 422 с путём body.guide.reasons.<шаг>); если это не удаётся, сессия остаётся открытой. POST /care-sessions/{id}/reopen снова открывает оба. Новое поле completedAt. Изменено: после завершения running равно false (раньше четыре часа от начала), а start для завершённой сессии отвечает conflict с session-completed.

v1.237.0 · 23 октября 2026 г.

  • Пайплайны, процесс продаж (PI.21): четвёртый тип закрытия parked (добавляется в пайплайн через POST /pipelines/{id}/stages с type: "parked", не более одного раза). Для откладывания нужны причина и followUpAt в будущем, иначе 422 с путём body.followUpAt (вид followUp в checkMove). Записи содержат followUpAt; каждый переход задаёт его заново. Прогноз указывает parked (количество, сумма) и не учитывает отложенные записи. Триггер pipelines.entry.closed фильтрует и по outcome parked.

v1.236.0 · 23 октября 2026 г.

  • У типов приёма появилось поле callGuideId: сценарий разговора (GET /call-guides), предлагаемый в разговоре и на встрече этого типа. Чтение в appointments.getType/listTypes, запись в createType/updateType (null — без сценария). Только активный сценарий этой организации, иначе validation-failed для body.callGuideId.

v1.235.0 · 23 октября 2026 г.

  • Изменено: PATCH /contacts/{id} переносит изменённый адрес эл. почты или номер телефона на интересентов партнёров, связанных с этим контактом, и отклоняет изменение, вместо того чтобы контакт и интересент расходились: 409 conflict с reason: prospect-email-taken, если новый адрес уже есть у другого интересента организации; 400 validation-failed для body.email (required), если адрес интересента без названия компании был бы удалён; 409 reason: prospect-not-saved, если интересента не удалось сохранить. Во всех трёх случаях контакт не изменён. Неизменённые поля ничего не запускают.

v1.234.0 · 22 октября 2026 г.

  • Пайплайны, закрытие в поддержке (PI.19): этапы содержат noReply (remindAfter, closeAfter, unit businessDays или days): напоминание и закрытие без ответа на этапе с остановленными часами, оба с коротким письмом клиенту (канал system). Записи содержат noReplyRemindAt, noReplyCloseAt, previousEntryId (ответ более чем через 14 дней после закрытия создаёт новое обращение; в течение 14 дней он снова открывает старое) и slaCredit (кредит один раз на обращение с нарушенным сроком, со структурированным calculation). Новые POST /pipelines/entries/{id}/sla-credit/release и …/discard (ORG_ADMIN, ORG_ACCOUNTANT; 409 sla-credit-decided, sla-credit-zero). Источник сообщения через API теперь human с OAuth-доступом человека, ai через API-MCP, иначе automatic. Прогноз указывает valueMode и risk; пайплайны поддержки возвращают там ожидаемые кредиты как отрицательные значения вместо null.

v1.233.0 · 22 октября 2026 г.

  • Пайплайны: два имени из 1.229.0 приведены к правилу для полей-счётчиков до выпуска: у SLA caseCount вместо casesCount, в slaTargets[] записи breachCount вместо breaches.

v1.232.0 · 22 октября 2026 г.

  • Формы: POST /responses/{id}/pdf требует forms:write вместо forms:read, как любая конечная точка, создающая PDF (invoices.renderPdf, orders.renderPdf, time.renderReportPdf): она создаёт документ и запускает создание. Статус (GET /responses/{id}/pdf/{documentId}) остаётся с forms:read. Версия 1.231.0 с forms:read никогда не выпускалась.

v1.231.0 · 22 октября 2026 г.

  • PDF отправки через API: POST /responses/{id}/pdf создаёт PDF на бланке организации (202 с documentId, status pending), GET /responses/{id}/pdf/{documentId} сообщает статус (pending, ready с url, failed), POST /responses/{id}/pdf/{documentId}/send отправляет его по e-mail клиенту карты. Формы карты клиента только с открытием клиентских данных, clients:read и доступом к картам у действующего лица; без доступа к картам 403 forbidden с reason client-access-required (теперь и для POST /form-templates/{id}/insert). Отправка: 422 not-a-client-form или contact-without-email, 409 pdf-not-ready.

v1.230.0 · 22 октября 2026 г.

  • Шаблоны библиотеки форм через API: GET /form-templates (собственные и предоставленные другими организациями, фильтр targetEntity, поиск q), GET /form-templates/{id} (предпросмотр в форме обращения addressForm), POST /form-templates/{id}/insert (новая форма из шаблона, 201 с определением и notes), POST /form-templates (предоставить собственную форму, с templateId как новую версию) и DELETE /form-templates/{id} (только собственные; вставленные формы остаются). Чтение с forms:read, запись с forms:write и только для администраторов организации; шаблон карты клиента только с доступом к картам (forbidden) и профилем практики (feature-not-available). targetEntity в GET /forms и GET /forms/{id} теперь называет все четыре цели (также VERTRIEBLER_PROFIL и VERTRIEB_FIRMENPROFIL); ответы уже содержали их, не хватало описания.

v1.229.0 · 22 октября 2026 г.

  • Пайплайны, поддержка с SLA (очередь 4): новый /pipelines/slas (чтение, создание, изменение с archived, удаление только неиспользуемых, иначе 409 sla-in-use) с календарём (weeklyHours как часы работы), сроками по видам (firstResponse, nextResponse, update, restore, resolution) и приоритетам с явной единицей (minutes, hours, businessMinutes, businessHours, businessDays), последствием в виде кредита с лимитом, клиентами. Новые GET/POST /pipelines/entries/{id}/messages (ответ клиенту уходит письмом; source определяет сервер, через API automatic). Записи содержат descriptionHtml, priority, requestedPriority, sla, slaStatus, slaDueAt, slaTargets, restoredAt (можно задать описание, приоритет, restored), этапы slaClock, пайплайны customerPortalRequests. События pipelines.entry.slaDueSoon, pipelines.entry.slaBreached, pipelines.message.created. Новая причина not-a-support-case.

v1.228.0 · 22 октября 2026 г.

  • Замена форм через API: PUT /forms/{id} заменяет форму целиком тем же телом, что и POST /forms (заголовок со значениями по умолчанию, где ничего не указано, страницы, элементы). То, чего тело не знает, остаётся (разрешения, ссылки, завершение, отображение); прежние отправки остаются доступными. Ответ 200 с определением и build. targetEntity изменить нельзя (422 в body.targetEntity); архивированная форма даёт 409 conflict с reason archived, как в POST /forms/{id}/responses, краткое имя другой формы 409 form-slug-taken. Только администраторы организации, scope forms:write. У причины archived теперь есть текст на странице ошибок.

v1.227.0 · 22 октября 2026 г.

  • Создание форм через API: POST /forms создаёт форму целиком (заголовок, страницы, элементы по kind: text, standardField, field с new для нового собственного поля, matrix, repeater; условия в condition; флажки в consents) тем же построителем, что и конструктор форм. Ответ 201 с определением как в GET /forms/{id} и build (createdFields, reusedFields, notes). POST /forms/validate проверяет то же тело без сохранения (valid, errors, notes, запланированные страницы, элементы и поля). GET /forms/building-blocks перечисляет стандартные поля, существующие собственные поля, типы для новых полей, синтаксис условий и структуру матрицы и повторителя. Только администраторы организации (иначе 403 forbidden); scope forms:write для создания, forms:read для проверки и строительных блоков. Ошибки 422 validation-failed с путём body.pages.<i>.elements.<j>… (индексы с 0) и кодом invalid_reference, required, invalid_value, invalid_combination или too_big; занятое краткое имя даёт 409 conflict с reason form-slug-taken (при проверке ошибка с этим кодом). Формы карты клиента только с профилем практики.

v1.226.0 · 22 октября 2026 г.

  • Формы: POST /forms/{id}/archive и POST /forms/{id}/unarchive архивируют форму или возвращают её из архива, как в конструкторе форм (scope forms:write, только администраторы организации, иначе 403 forbidden; ключ без действующего лица получает no-acting-user). Ответ 200 с формой; повторный вызов ничего не меняет. Архивированная форма ничего не принимает по своим ссылкам, POST /forms/{id}/responses отвечает 409 (archived). Новое в GET /forms/{id}: consentMode, вид согласия формы (none, optional, promotion).

v1.225.0 · 22 октября 2026 г.

  • Ключи партнёров (API лидов): помимо ключей организации есть ключи, привязанные ровно к одному партнёру (аффилиату); их выдаёт партнёр в портале партнёра или администратор организации. Ключ партнёра вызывает только GET /forms/{id}, POST /forms/{id}/responses и POST /appointment-types/{id}/partner-links, иначе 403 forbidden с reason partner-key-endpoint; API-MCP его не принимает. Он всегда отправляет данные для своего партнёра (другой affiliateId даёт 422 в body.affiliateId, код partner-affiliate), видит только формы, открытые для портала партнёра и создающие потенциальных клиентов (иначе 404), и только потенциальных клиентов своего партнёра. В GET /forms/{id} responseCount тогда считает только отправки его партнёра, а publicUrl равен null. Инструкция: /developers/partner-leads.

v1.224.0 · 22 октября 2026 г.

  • E-mail-кампании двух видов (kind: marketing или notice). Уведомление (notice) отправляется всем из выборки без согласия на рекламу и без ссылки для отписки, использует шаблоны с purpose transactional и не требует проверки перед стартом (deepCheckRequired). Содержимое теперь хранится в кампании: subject, bodyHtml, subjectInformal, bodyHtmlInformal и salutation, скопированы из шаблона и изменяемы без изменения шаблона (template с modified). Кроме того, document (документ как личная ссылка для каждого получателя, linkExpiresDays) и attachment (PDF до 5 МБ). GET /email-campaigns/setup называет kinds, personalSender и kind для каждого шаблона; GET /email-campaigns фильтрует по kind, POST /email-campaigns/recipient-count принимает kind. Новое: POST /email-campaigns/{id}/document/replace (исправленная версия, ссылки сохраняются), а также GET и PUT /email-campaigns/notice-permissions (кто помимо администраторов может отправлять уведомления). Участники с этим правом видят через API только уведомления и отправляют со своего личного адреса SendGrid (senderLocalPart и senderDomain тогда можно не указывать); для администраторов всё остаётся как прежде. kind после создания изменить нельзя (422 immutable). Новые ошибки: 422 unknown-field в body.bodyHtml для несуществующих полей, 403 campaign-kind-not-allowed, 422 notice-sender-missing, download-links-not-configured и campaign-document-missing.

v1.223.0 · 22 октября 2026 г.

  • Формы: два значения bookingError у POST /forms/{id}/responses теперь называются так же, как у appointments.createPartnerLink (1.220.0): prospect-without-contact вместо contact-missing и appointment-type-not-released-to-partner вместо appointment-type-not-released. Старые названия из 1.221.0 никогда не выпускались.

v1.222.0 · 22 октября 2026 г.

  • Новый вид оповещения AUTOMATION_RUN_HALTED (в GET /organization/api-alerts и PUT /organization/api-alerts/rules/{kind}): если автоматизация останавливает выполнение по устранимой причине (precondition-failed с fixable: true), владелец и администраторы организации получают уведомление в колокольчике, по желанию также по e-mail, не чаще одного раза за 24 часа для каждого правила и причины. Исключение: недостающие обязательные данные этапа пайплайна, в этом случае по-прежнему создаётся задача.

v1.221.0 · 22 октября 2026 г.

  • Формы: POST /forms/{id}/responses дополнительно принимает appointmentTypeId и senderContactId. С типом приёма ответ дополнительно содержит bookingUrl, персональную партнёрскую ссылку для записи нового заинтересованного лица (запись у посредника без повторного ввода данных), или bookingError, почему её нет: prospect-not-found (нет заинтересованного лица, например без посредника), contact-missing, appointment-type-not-released, sender-not-in-team, booking-failed. Если не удалась только ссылка, отправка сохраняется (201). Для этого ключу дополнительно нужно право appointments:write, иначе 403 insufficient-scope до отправки. С партнёрским ключом ссылка работает только для заинтересованных лиц своего посредника. Без appointmentTypeId ответ не меняется.

v1.220.0 · 22 октября 2026 г.

  • Новое: POST /appointment-types/{id}/partner-links (appointments.createPartnerLink) по prospectId возвращает персональную ссылку партнёра для записи этого потенциального клиента, существующую или новую (kind PARTNER, с contactId, affiliateId, senderContactId). Те же правила, что и в портале партнёра: только типы приёма, открытые партнёру, отправитель из его команды (необязательно senderContactId, иначе ответственный за потенциального клиента или владелец партнёра). Новые причины для precondition-failed: prospect-without-contact, appointment-type-not-released-to-partner.

v1.219.0 · 22 октября 2026 г.

  • Пайплайны: сценарии прогноза называются worst, normal, best (в forecast.months[].weightedCents, в группах и в effectiveProbability этапов), поля этапов для записи — probabilityWorst/probabilityBest. Они заменяют bad/good и probabilityBad/probabilityGood из версии 1.218.0, которая не выпускалась.

v1.218.0 · 22 октября 2026 г.

  • Пайплайны, прогноз и обучение: новый GET /pipelines/{id}/forecast (двенадцать месяцев начиная с текущего, взвешенная стоимость по месяцам в сценариях bad, normal, good, группы overdue, withoutDate, later, доля измерения, источник даты; по каждому открытому этапу действующая вероятность, время на этапе и срок до закрытия; forecast равен null без режима revenue). У этапов есть effectiveProbability (действующая вероятность по learningMode со сценариями, measuredPercent, decidedCases) и probabilityBad/probabilityGood (сценарии вручную, задаются через POST/PATCH .../stages). Поведение: learningMode теперь действует; probability и weightedValueCents записи без переопределения считаются по действующей вероятности этапа, а не по значению по умолчанию (при learningMode default без изменений).

v1.217.0 · 22 октября 2026 г.

  • Пайплайны: в couplings есть prospectsRequired (потенциальные клиенты партнёров ведутся в этом пайплайне; если партнёр работает с клиентом без записи, портал просит привязать его) и prospectsAutomatic (создавать во входном этапе без вопроса), читаются в GET /pipelines/{id}, задаются через PATCH /pipelines/{id}.

v1.216.0 · 22 октября 2026 г.

  • Автоматизации: три новых действия для пайплайнов в каталоге (GET /automation-catalog) и в POST/PATCH /automations, по одному эндпоинту: pipelines.createEntry (создать запись), pipelines.moveEntries (установить этап, в том числе закрыть с причиной; последняя или все открытые записи контакта либо определённая) и pipelines.updateEntry (сумма, ответственный, дата закрытия). Обязательные данные этапа действуют и здесь: если чего-то не хватает, шаг завершается ошибкой, которую можно исправить. Новые виды фильтров pipeline и pipelineStage («одно из») у триггеров pipelines.entry.*, при закрытии outcome. Новые источники дат pipelines.entry.expectedCloseDate и pipelines.entry.rotting (запись слишком долго на своём этапе). Источники полей pipeline, pipelineStage, pipelineReason, объект entry. Исправлено: фильтры «одно из» до сих пор не действовали для триггеров по дате.

v1.215.0 · 22 октября 2026 г.

  • Пайплайны, связи: у пайплайнов есть couplings (quoteValue, quoteAcceptedStageId, paidMeansSuccessful, leadSources), читаются в GET /pipelines и GET /pipelines/{id}, задаются через PATCH /pipelines/{id} (leadSources заменяет список целиком). Новые GET /pipelines/assignments и POST /pipelines/assignments/{id}/resolve: открытые привязки оплат, принятых предложений и лидов к записи, если запись неоднозначна. Новый POST /pipelines/entries/move для автоматизаций: задать этап конкретной записи, самой новой открытой или всех открытых записей контакта; всё или ничего, недостающие данные как precondition-failed с stage-requirements-missing и fixable: true.

v1.214.0 · 22 октября 2026 г.

  • Пайплайны: у этапов есть необязательный цвет color (один из двенадцати цветов категорий, как color в сценариях звонков; null — без цвета), читается в GET /pipelines/{id} и задаётся через POST /pipelines/{id}/stages и PATCH /pipelines/{id}/stages/{stageId}. У пайплайна есть stageColorDisplay (dot — точка рядом с названием, fill — заголовок в полном цвете), по умолчанию dot, задаётся через PATCH /pipelines/{id}.

v1.213.0 · 21 октября 2026 г.

  • Новое: материалы к занятию для комнаты (область appointments). GET/PUT /appointment-types/{id}/lesson-media читает или заменяет список типа встречи (assetIds, не более 50, порядок = position). GET/PATCH /appointments/{id}/lesson-media показывает действующий список встречи (media) и её отличия (added, hidden); add добавляет материалы только к этой встрече, hide скрывает материалы типа встречи, заданное поле заменяет свой список. После окончания встречи 422 precondition-failed с appointment-ended. GET /lesson-media/options ищет видео и PDF в библиотеке (q). Изменение требует права управлять встречами.

v1.212.0 · 21 октября 2026 г.

  • Формы, только поведение, для отправок по публичной ссылке (/f/…): если человек надёжно известен (персональная ссылка на контакт, запомненное устройство или адрес e-mail, подтверждённый кодом) и для именно этого адреса или номера в поле есть согласие на рекламу не старше 24 месяцев и не отозванное, форма не спрашивает повторно. Отправка (GET /forms/{id}/responses, GET /responses/{id}, forms.response.submitted) тогда не содержит для этого канала записи с purpose MARKETING; это не отказ, состояние согласия хранится у контакта. Поставленная галочка отображается как прежде. Отправки через POST /forms/{id}/responses это не затрагивает.

v1.211.0 · 21 октября 2026 г.

  • Новое: пайплайны (раздел pipelines, права pipelines:read и pipelines:write). GET/POST /pipelines, GET/PATCH /pipelines/{id}, этапы (/pipelines/{id}/stages, порядок через PUT …/stages/order) и причины закрытия (/pipelines/{id}/reasons); пайплайны и этапы ведут только администраторы организации. Записи в /pipelines/entries: создание, изменение, move (также закрытие), move/check, reopen, history. При перемещении действуют те же требования, что и в приложении, при пропуске — суммарно: если чего-то не хватает, вернётся 422 с ошибкой stage-requirement на каждое; при запрете — precondition-failed с stage-skip-locked или stage-back-locked (fixable: false), архивный пайплайн — pipeline-archived (fixable: true). События pipelines.entry.created, .stageChanged, .closed, .valueChanged. Суммы как valueCents. Также DELETE /articles/{id}: 409 in-use и тогда, когда записи пайплайнов берут сумму из этого артикула (usage.pipelineEntries).

v1.210.1 · 21 октября 2026 г.

  • Поведение: источник mollie прогноза подписок (/provider-subscriptions) возвращает цифры, как только организация подключит Mollie с разрешением subscriptions.read (новые подключения его запрашивают, существующие подключаются заново один раз). Считываются подписки всех профилей Mollie организации, синхронизация ночью и через POST /provider-subscriptions/sync; netCents остаётся пустым (Mollie не указывает нетто). До повторного подключения остаётся needs-reconnect. Спецификация не меняется.

v1.210.0 · 21 октября 2026 г.

  • Новое: прогноз подписок, созданных непосредственно у платёжного провайдера (не собственных подписок claritos в /subscriptions). GET /provider-subscriptions выводит зеркало (фильтр source: stripe-connect, stripe-platform, mollie; status; contactId по e-mail). GET /provider-subscriptions/forecast возвращает по каждой валюте текущий месяц с сегодняшнего дня и следующие одиннадцать месяцев, брутто или с net=true нетто, а для каждого источника state, syncedAt, needsReconnect. POST /provider-subscriptions/sync запускает синхронизацию (202; 409 sync-locked с retryAfter, 409 source-not-ready). Права subscriptions:read и subscriptions:write. Mollie сообщает needs-reconnect, пока организация не подключит Mollie заново с доступом к подпискам.

v1.209.0 · 21 октября 2026 г.

  • Изменено: GET /affiliates/activity теперь учитывает в emails и письма из почтовых ящиков партнёров в партнёрском портале (почтовый клиент и сценарии разговора), в том числе по человеку (people[].counts.emails, раньше null). Сохраняются только время, человек и число получателей, без содержания; учёт с момента введения. Отправки рекламных материалов учитываются только до первой такой записи организации, иначе одно письмо считалось бы дважды. Пример исправлен: previousPeriod той же длины, что и period.

v1.208.0 · 21 октября 2026 г.

  • Новое: подписка непосредственно из первого счёта. У счетов есть поле subscription (intervalMonths от 1 до 60, periods от 2 до 600 или null = до расторжения; null = без подписки), доступное для чтения и записи через POST /invoices и PATCH /invoices/{id}. При фиксации (POST /invoices/{id}/issue) создаётся подписка, счёт становится её первым периодом (billingContractId); период оказания услуг устанавливается на этот период. Ошибки: 422 в body.subscription…, body.contactId или body.items, 409 subscription-exists.
  • Новое: статус подписки AWAITING_FIRST_PAYMENT (GET /subscriptions, фильтр status): создана из счёта, первый счёт ещё не оплачен. После оплаты подписка переходит в ACTIVE, а подлежащие выставлению последующие счета создаются сразу; сторнирование первого счёта переводит её в CANCELLED. Клиентам, знающим только прежние четыре значения, не следует считать неизвестный статус действующим.

v1.207.0 · 21 октября 2026 г.

  • Новое: GET /affiliates/activity возвращает активность аффилиатов, как блок на панели: звонки и время разговоров, встречи (по записи и в видеокомнатах), продажи с выручкой по валютам, новые интересенты, сообщения (e-mail, SMS, письма) и выполненные задачи по аффилиату и человеку за период от from до to (по умолчанию последние 30 дней) и за такой же период до этого. Фильтр affiliateId. Только с управлением аффилиатами в лицензии, иначе 403 feature-not-available.

v1.206.0 · 21 октября 2026 г.

  • Новое: GET /contacts фильтрует по ответственному с параметром responsible, через запятую (не более 20): идентификаторы пользователей-участников, me для действующего лица ключа, partner для контактов, которые ведёт только партнёр. Действует то же правило, что и в фильтре «Ответственный» в приложении (участник перед партнёром; покинувший организацию не учитывается); responsible=me соответствует переключателю «Только мои». Ключ без создателя получает для me 422 no-acting-user, неизвестное значение 400 validation-failed.

v1.205.1 · 21 октября 2026 г.

  • Исправлено: DELETE /invoices/{id} отвечал на черновик 204, не удаляя его (с 1.179.0; затронут каждый черновик, не относящийся к расчёту кредитов). Теперь он удаляется. Если при этом не удалена ни одна строка (например, потому что черновик в тот же момент был зафиксирован), эндпоинт отвечает 404 not-found вместо 204. Черновики расчёта кредитов по-прежнему дают 409 credits-run.

v1.205.0 · 21 октября 2026 г.

  • Изменено: POST/PATCH /message-templates принимают поле {{terminlink.<id-типа-встречи>}} (ранее 400 unknown-field). Допустимы при usage: contacts типы встреч с персональной ссылкой, для партнёрского портала открытые для партнёров; иначе 400 unknown-field с указанием типа встречи. При отправке из поля получается персональная ссылка для записи для каждого получателя (в HTML ссылкой). Новое: если её нельзя создать для контакта, POST /outbound-emails и POST /sms с vorlageId отвечают 422 и reason: booking-link-unavailable, а не отправляют письмо с пустым местом.

v1.204.0 · 21 октября 2026 г.

  • Новое: reminderService в POST /appointments: клиент хочет получать напоминания о приёме (сервис напоминаний), только по его прямой просьбе, без указания — нет; только для индивидуального приёма, фиксируется для адреса электронной почты и мобильного номера контакта с источником «API»; ранее сделанный клиентом отзыв остаётся. Изменено: напоминания перед приёмом снова планируются для клиентов, но отправляются только при этом согласии (проверка при отправке, именно для этого адреса или номера), и каждое содержит ссылку для отписки. Подтверждение, отмена и перенос отправляются всегда.

v1.203.0 · 20 октября 2026 г.

  • Новое: contactId в POST /appointment-types/{id}/links возвращает персональную ссылку записи этого контакта, существующую или новую (kind PERSONAL): приём привязан к контакту; если у типа приёма нет анкеты, запись идёт без дополнительных данных. Для типа приёма нужно разрешение «персональная ссылка»; новые причины для precondition-failed: appointment-type-not-personal, appointment-type-internal-only. Без contactId, как и раньше, новая открытая ссылка.

v1.202.0 · 20 октября 2026 г.

  • Новое: reminderPlanId в POST /appointment-types и PATCH /appointment-types/{id} назначает типу встречи план напоминаний (GET /appointment-reminder-plans), null — без напоминаний. Если не указан, новый тип встречи получает план организации по умолчанию, существующий сохраняет свой. Изменено: напоминания перед встречей не планируются для клиентов, пока они не согласятся на сервис напоминаний; подтверждение, отмена и перенос отправляются всегда.

v1.201.0 · 20 октября 2026 г.

  • Напоминания о задачах (ядро KR.41). Новое: GET /tasks/reminder-settings и PUT /tasks/reminder-settings (tasks:read/tasks:write, запись только для администраторов организации) читают и задают настройки: моменты до срока в minutesBefore (0, 15, 60, 180, 1440, 2880, 10080; неизвестные значения отбрасываются без ошибки) и способы в channels (BELL, EMAIL, SMS). Без сохранённых настроек действует колокольчик в срок; эл. почта и SMS только после включения администратором. Задачи со сроком теперь вызывают напоминания ответственному, в том числе созданные через API. Новое у задачи: dueHasTime (содержит ли dueDate время). При записи dueDate дата без времени или полночь UTC считается датой без времени; без времени срок наступает в свой день, напоминание приходит в 8:00 (Берлин). kind у SMS (GET /sms, события sms.message.*) получил новое значение TASK_REMINDER.

v1.200.0 · 20 октября 2026 г.

  • Новое: PATCH /telephony (telephony.updateOptions) включает или выключает распознавание автоответчика организации (answeringMachineDetection), а GET /telephony показывает его состояние в новом поле answeringMachineDetection (без подключённого аккаунта false). Изначально распознавание включено для каждой организации: при исходящих звонках Twilio сообщает, ответил ли человек, автоответчик или факс; это нужно статистике звонков, чтобы считать голосовую почту. Оно работает в фоне, вызываемый абонент не ждёт, а Twilio взимает плату за каждый принятый звонок со счёта организации. Только ORG_ADMIN, право telephony:write.

v1.199.0 · 20 октября 2026 г.

  • Новое: сессии сопровождения (практика BP.2). GET /care-enrollments/{id}/sessions выводит открытые сессии, GET /care-sessions/{id} читает одну. POST /care-enrollments/{id}/sessions/open открывает сессию на позиции копии (при первом открытии создаётся, затем та же), POST /care-enrollments/{id}/sessions создаёт внеплановую сессию вне плана (adHoc, без position; например при кризисе, только в активном или приостановленном сопровождении, иначе conflict с enrollment-ended). POST /care-sessions/{id}/start начинает сессию: running равно true в течение четырёх часов. PATCH /care-sessions/{id} задаёт тип сессии (standard, safety, gentle, catch-up, relief) с краткой причиной. Права как у сопровождений: careplans:read/:write и clients:read/:write, разрешение на данные клиентов, журнал доступа. У прохождения сценария сессии нет эндпоинта; его ID указан в guideRunId.

v1.198.0 · 20 октября 2026 г.

  • Формы, только поведение, для отправок по публичной ссылке (/f/…): (1) Если в форме с рекламой e-mail или телефон подтверждаются ссылкой после отправки, согласие на рекламу запрашивается только после отправки. «Да» затем добавляется к отправке: GET /forms/{id}/responses и GET /responses/{id} показывают принятое согласие с purpose MARKETING, которого не было в forms.response.submitted при отправке; отдельного события для последующего «да» нет. «Нет» ничего не оставляет. Согласие на рекламу вступает в силу только после перехода по ссылке в подтверждении. (2) Новый вид согласия «рекламная акция»: кнопка отправки выражает желание получать рекламу, текст стоит над ней. Отправка содержит согласие как accepted true, хотя галочка не показывалась. Отправки через POST /forms/{id}/responses это не затрагивает; там согласия на рекламу остаются галочками.
  • Только документация: пример GET /forms/{id} теперь показывает необязательную галочку для рекламы (purpose MARKETING, required false) вместо отменённой галочки запроса (purpose INQUIRY, с 1.197.0). Пример отправки сохраняет INQUIRY, потому что прежние отправки его содержат.

v1.197.0 · 20 октября 2026 г.

  • Формы, только поведение: обязательная галочка «связь по моему запросу» (purpose INQUIRY) отменена. Для ответа на запрос согласие не нужно; вместо этого форма показывает уведомление о защите данных. GET /forms/{id} больше не указывает в consents согласие с INQUIRY. Согласия на рекламу (MARKETING) и прежние галочки, объединяющие запрос и рекламу (purpose null, канал e-mail или телефон), появляются, только если форма разрешает рекламу; это значение по умолчанию для всех существующих форм. Собственные согласия (канал CUSTOM) не изменились. POST /forms/{id}/responses больше не требует галочку запроса для e-mail или телефона: validation-failed с body.consents.<elementId> теперь возникает только для собственных обязательных согласий и прежних объединённых галочек. Переданное true для отменённой галочки не является ошибкой, оно не сохраняется. Новые отправки (GET /forms/{id}/responses, forms.response.submitted) и consent/consentPurposes события leads.lead.created больше не содержат INQUIRY; прежние отправки его сохраняют, поэтому значение остаётся в схеме.

v1.196.0 · 20 октября 2026 г.

  • Изменено: серии встреч содержат до 100 шагов вместо 10. В POST /appointment-series-templates и PATCH /appointment-series-templates/{id} поле steps принимает от 2 до 100 шагов, samePersonAsStep до 100; так же appointments в POST /appointment-series, {step} в /appointment-series/{id}/steps/{step} и following в POST /appointments/{id}/reschedule-with-series.

v1.195.0 · 19 октября 2026 г.

  • Изменено: текст шага напоминания (bodyHtml, также в informal) в PATCH /appointment-reminder-steps/{id} теперь сохраняет только разметку редактора: абзацы, полужирный, курсив, подчёркивание, зачёркивание, списки и переносы строк. Ссылка превращается в свой текст, изображения и атрибуты удаляются. Подтверждение, отмена и перенос отправляются всегда и не должны содержать рекламных элементов.

v1.194.0 · 19 октября 2026 г.

  • Новое, только для ORG_ADMIN: читать оповещения API организации (GET /organization/api-alerts: вызовы и ошибки за 24 часа и 7 дней, правила по видам, последние оповещения, адрес оповещений), настроить вид оповещения (PUT /organization/api-alerts/rules/{kind}) и задать адрес оповещений (PUT /organization/api-alerts/email). Кроме того, читать установки приложения claritos в LeadConnector (GET /organization/integrations/leadconnector) и отключать установку (DELETE /organization/integrations/leadconnector/{id}); устанавливают по-прежнему в самом LeadConnector. Права organization:read или organization:write.

v1.193.0 · 19 октября 2026 г.

  • Новое событие careplans.enrollment.resumed: приостановленное сопровождение снова идёт (статус ACTIVE из PAUSED). Полезная нагрузка как у остальных careplans.enrollment.* (только идентификаторы и состояния); данные клиентов, только на endpoints с clientsData. Доступно и как триггер автоматизаций.

v1.192.0 · 19 октября 2026 г.

  • Новое: firstSessionIsOnboarding в GET /care-plans/{id} (и в ответах остальных endpoints шаблонов) и в copy сопровождений. true означает: сессия 1 является онбордингом и в интерфейсе называется сессией 0; позиции, серия и временные окна по-прежнему считаются с 1. Записывается в POST/PUT /care-plans и в пробном прогоне POST /care-plans/validate, необязательно; без указания false, также при PUT, потому что дерево заменяется целиком.

v1.191.0 · 18 октября 2026 г.

  • Новое: область careplans (планы сопровождения практики), права careplans:read/careplans:write, группа «Контакты и клиенты». Шаблоны: GET/POST /care-plans, GET/PUT/DELETE /care-plans/{id}, GET /care-plans/options, пробный прогон POST /care-plans/validate, POST /care-plans/{id}/release, …/retire, …/versions. План записывается целиком (заголовок, фазы, сессии), изменить можно только собственный черновик (409 plan-not-draft), пробелы до утверждения перечислены в gaps. Сопровождения (данные клиентов, дополнительно clients:read/clients:write и разрешение данных клиентов, журнал доступа): GET/POST /care-enrollments, GET /care-enrollments/{id}, GET /clients/{id}/care-enrollments, POST /care-enrollments/{id}/events, …/status, приёмы через GET …/appointment-proposal и POST …/appointments (плюс appointments:read/appointments:write). Везде лицензионное право практики и действующее лицо с доступом к картам клиентов; утверждение и отзыв только с правом утверждения. События careplans.enrollment.started, .paused, .ended (только на endpoints с clientsData, только идентификаторы и состояния).

v1.190.0 · 18 октября 2026 г.

  • Новое в разделе biomarkers: наборы правил биомаркеров. GET/POST /biomarker-rule-sets, GET/DELETE /biomarker-rule-sets/{id}, PUT …/{id}/rules (правила целиком), POST /biomarker-rule-sets/validate (пробный прогон без сохранения), POST …/{id}/confirm и …/{id}/unconfirm. Условия на английском (value, unit, present/missing), маркеры как ключи списка практики. Подтверждать может только пользователь с правом утверждения, никогда автоматизация (403 confirm-needs-person); подтверждённый набор не изменяется (409 rule-set-confirmed).

v1.189.1 · 18 октября 2026 г.

  • Поведение: продление срока (POST /dunning/open-items/{openItemId}/extension, dueDate) теперь действует до конца предоставленного дня (UTC), а не только до 00:00. Поэтому в сам предоставленный день повторное продление отвечает 409 extension-exists, а процедура напоминаний продолжается только со следующего дня. Сохранённая и напечатанная дата не меняются.
  • Поведение: DELETE /articles/{id} теперь отвечает 409 in-use также, если артикул есть в позициях предложений или заказов (любой статус), в договорах подписки, в кредит-нотах комиссий, в настройках организации, является артикулом комиссии кампании или привязан к хуку доступа. Для этого в usage есть поля quoteLines, orderLines, subscriptionLines, commissionCreditLines, accessHooks, organizationSettings, campaignCommissions. Вместо удаления: архивировать.

v1.189.0 · 18 октября 2026 г.

  • Новое: раздел biomarkers (биомаркеры практики, только при праве организации «Практика»). GET /biomarker-profiles выдаёт профили биомаркеров со статусом, версией, количеством маркеров и deletable/deleteBlockedBy; DELETE /biomarker-profiles/{id} удаляет профиль, пока он ни разу не использовался (не утверждался, не входит в заявку в лабораторию, не передавался, нет следующей версии), иначе 409 conflict с reason. Чтение и запись требуют действующего пользователя с доступом к картам; профили не являются данными клиентов.

v1.188.0 · 18 октября 2026 г.

  • Новое в mailboxes.*: attachmentHandling (receipt, receiptStack, document или null) задаёт, как обрабатываются вложения писем в общий почтовый ящик, как адреса по видам на inbox.claritos.io. Каждый вид принадлежит не более чем одному общему почтовому ящику в организации; иначе 409 с reason: handling-taken. Личные почтовые ящики всегда возвращают null.

v1.187.0 · 18 октября 2026 г.

  • Новые права biomarkers:read/biomarkers:write для биомаркеров практики (профили с референсными значениями). Они подготовлены для адресов, которые появятся позже; до тех пор они не дают доступа. Существующие ключи и доступы OAuth не получают их автоматически.

v1.186.0 · 18 октября 2026 г.

  • Новое в разделе credits: расчёты (/credits/runs: предварительный расчёт, список, чтение, запуск, проведение, отмена, сторно, отправка и пересоздание выписок; запуск, проведение и сторно выполняются в фоне, ответ 202), импорт (/credits/import-profiles: профили, проверка, загрузка, идентификаторы, перенос остатка, основные данные; POST /credits/import-files/header; список в Base64, не более 600 КБ), покупки с портала (/credits/portal-purchases, счета к ним с invoices:write), комиссии (/credits/commissions, сверка) и курирование (PUT /credits/accounts/{id}/supervision, DELETE /credits/supervisions/{id}).

v1.185.0 · 18 октября 2026 г.

  • Новое: раздел credits (программа кредитов, только при праве CREDITS организации): программы GET/POST /credits/programs, GET/PATCH /credits/programs/{id}, PUT/DELETE …/{id}/logo; счета GET/POST /credits/accounts (список с from/to), GET/PATCH /credits/accounts/{id}, POST …/{id}/entries (ручное начисление или корректировка), PUT …/{id}/bonus-rules. Запись требует действующего пользователя с ORG_ADMIN или ORG_ACCOUNTANT. Значения на английском (WEEKLY, PREPAID, USAGE, GRANT …).

v1.184.0 · 18 октября 2026 г.

  • Новое: отчёты по времени в разделе time: GET /time-reports (фильтр по проекту и статусу), GET /time-reports/preview, POST /time-reports (фиксация времени проекта за период), GET /time-reports/{id} (с записями), POST …/{id}/discard, POST …/{id}/pdf и POST …/{id}/bill (черновик счёта; нужны time:write и invoices:write и действующий пользователь, создаёт invoices.invoice.created). Выставление отклоняет время, уже выставленное другим отчётом (entries-already-billed).

v1.183.0 · 18 октября 2026 г.

  • Новое: шаблоны счетов в разделе templates: условия оплаты (/payment-terms) и вступительные и заключительные тексты (/text-blocks), с чтением, созданием, изменением, удалением и POST …/{id}/default; неформальные варианты в informal. Удаление отправляет в архив шаблон, который ещё используется в документах, контактах или настройках кредит-нот (mode: archived). А также GET/PATCH /contacts/{id}/billing-defaults (раздел contacts).

v1.182.0 · 18 октября 2026 г.

  • Новое: GET /payments/events (события платежей подключения Stripe, фильтр по серьёзности и виду, onlyProblems), расчёты возмещения ущерба GET/POST /settlements и GET /settlements/{id} (область invoices; создание требует действующего лица и confirmGenuineDamage: true), а также POST /files/rich-images (подписанный адрес загрузки изображений для форматированных описаний; первый эндпоинт в области files).

v1.181.0 · 18 октября 2026 г.

  • Артикулы полностью: DELETE /articles/{id} (только неиспользуемые; иначе 409 conflict с in-use и usage, тогда архивируйте), значок через POST /articles/{id}/icon-upload, POST /articles/{id}/icon и DELETE /articles/{id}/icon, GET /articles/catalog-range (ценовой диапазон номера каталога). При создании и изменении — новые groupName, isSelectable и catalog; при чтении дополнительно usageCount. Новое событие articles.article.deleted.

v1.180.0 · 18 октября 2026 г.

  • Счета полностью: POST/DELETE /invoices/{id}/service-rendered (услуга оказана с проводкой, ровно один раз), исправления по § 31 абз. 5 UStDV (GET/POST /invoices/{id}/correction-notes, GET …/correction-notes/{correctionId}/email, POST …/send), план платежей (GET /invoices/{id}/installment-plan, POST …/installment-plan/collect, POST …/installment-plan/accelerate), GET /invoices/{id}/fee-schedule-check (GebüH), разрешение отправки (POST /invoices/release-dispatch) и прогоны по плану (GET /invoices/plan-runs, POST /invoices/plan-runs/release, POST /invoices/plan-runs/direct-debit; разрешение и перевод только ORG_ADMIN), а также счёт к платежам Stripe (GET /invoices/stripe-payments, POST /invoices/stripe-payments/prepare, POST /invoices/stripe-payments/invoice; только ORG_ADMIN и ORG_ACCOUNTANT).

v1.179.0 · 18 октября 2026 г.

  • Счета: DELETE /invoices/{id} (только черновики; иначе 409 conflict с not-draft, черновики прогона кредитов — credits-run), POST /invoices/{id}/duplicate, GET /invoices/{id}/email (предложение), POST /invoices/{id}/send (сам не выставляет: 409 conflict с not-issued; счета, выставленные задним числом, — awaiting-release), POST /invoices/{id}/mark-sent (отправка вне claritos, всегда текущим моментом), GET /invoices/{id}/refund-preview, POST /invoices/{id}/pdf (сформировать предпросмотр и дождаться) и POST /invoices/{id}/pdf/regenerate (заново сформировать официальный PDF). Сторно через POST /invoices/{id}/correct теперь принимает refundDays (срок возврата).
  • Изменение поведения: POST /invoices, POST /invoices/{id}/issue и POST /invoices/{id}/correct требуют действующего лица (no-acting-user), ранее 500 internal для ключа без создателя. GET /invoices/{id}/pdf и POST /quotes/{id}/convert требуют его только при формировании PDF или если предложение нужно сначала выставить; предложения писем (GET …/email для счетов, заказов и предложений) работают без лица — с подписью и отправителем организации. Копирование счёта теперь генерирует invoices.invoice.created.

v1.178.2 · 18 октября 2026 г.

  • Поведение, спецификация та же: POST /open-items/{id}/payments теперь требует действующего лица, если создаётся проводка, и без него отвечает 403 no-acting-user. Ранее ключ без создателя завершался там ошибкой 500 internal. markOnly: true (без проводки) по-прежнему работает без действующего лица.

v1.178.1 · 18 октября 2026 г.

  • Поведение, спецификация та же: POST /tasks, POST /tasks/{id}/comments и POST /time-entries (без userId) для ключа API без указанного создателя теперь отвечают 403 no-acting-user вместо 500. Раньше в ядро передавался пустой пользователь. Для доступа OAuth и ключей с создателем ничего не меняется; для POST /time-entries явно переданный userId остаётся действительным.

v1.178.0 · 18 октября 2026 г.

  • Заказы полностью: POST /orders (черновик с настройками контакта, позиции и разделы можно передать сразу), PATCH /orders/{id} (до первого выставления счёта, иначе 409 conflict с locked), DELETE /orders/{id} (только черновики без номера, иначе not-draft), POST /orders/{id}/issue (номер заказа и PDF), POST /orders/{id}/send (подтверждение заказа по e-mail), GET /orders/{id}/email (предложение), POST /orders/{id}/duplicate, POST /orders/{id}/pdf (сформировать предпросмотр или выставленную версию и дождаться её), POST /orders/{id}/invoices (частичный, итоговый или авансовый счёт как черновик; дополнительно нужен invoices:write), POST /orders/{id}/lines/{lineId}/drop и …/restore (исключить позицию и вернуть её; если количества тем временем изменились — 409 conflict с line-changed). Создание, копия, выставление, отправка и PDF требуют действующего лица.
  • Новое событие orders.order.sent: подтверждение заказа отправлено по e-mail из приложения или через API, с sentTo.
  • Изменение поведения предложений: POST /quotes, POST /quotes/{id}/issue, POST /quotes/{id}/send и GET /quotes/{id}/pdf (если формируется предпросмотр) теперь требуют действующего лица и без него отвечают no-acting-user. Ранее ключ без создателя завершался там ошибкой 500 internal.

v1.177.0 · 18 октября 2026 г.

  • Предложения полностью: GET /quotes/{id}/email (предложение письма с отправителем и готовностью к отправке), POST /quotes/{id}/remind (напомнить сейчас, только SENT), POST /quotes/{id}/duplicate (глубокая копия как черновик; требуется действующее лицо), DELETE /quotes/{id} (только черновики без номера, иначе 409 conflict с not-draft) и вложения: GET и POST /quotes/{id}/attachments, DELETE /quotes/{id}/attachments/{documentId}, PUT /quotes/{id}/attachment-order.

v1.176.0 · 18 октября 2026 г.

  • Новое: дела о взыскании. GET /dunning/collection-cases (фильтр status: pending, released, withdrawn, all), GET /dunning/collection-cases/{id}, POST …/release (recipientEmail, coverLetterHtml; claritos собирает дело из счёта, подтверждения услуги и PDF напоминаний и отправляет его коллекторскому агентству; требуется действующее лицо) и POST …/withdraw (пока дело не передано). Подтверждение и отзыв защищены от одновременных вызовов (409 conflict с wrong-status).

v1.175.0 · 18 октября 2026 г.

  • Новое: запись напоминаний. POST /dunning/reminders/{id}/finalize (номер, проводка, PDF), …/regenerate, …/discard (только черновики), GET …/email (предложение письма-напоминания) и POST …/send (недостающие поля из предложения; 409 conflict с sender-reconnect-required, если почтовый ящик нужно переподключить), POST /dunning/reminders/regenerate-unsent, POST /dunning/open-items/{openItemId}/extension (продление срока с dueDate и reason) и POST /dunning/run (прогон, 202). Фиксация, пересоздание, письмо и отправка требуют действующего лица (no-acting-user). Новое событие dunning.reminder.finalized, также как триггер автоматизаций.

v1.174.0 · 18 октября 2026 г.

  • Новое: наборы и ступени напоминаний — первые адреса с записью в разделе напоминаний. GET и POST /dunning/profiles (seedPreset создаёт стандартные ступени), GET, PATCH (isDefault: true делает набор набором по умолчанию) и DELETE /dunning/profiles/{id} (архивирует), POST /dunning/profiles/{id}/duplicate; ступени POST /dunning/profiles/{id}/levels, PATCH и DELETE /dunning/levels/{id}, PUT /dunning/profiles/{id}/level-order, PUT …/sepa-return-level и PUT …/extension-levels/{variant} (pre-final, post-final; без полей — шаблон). Набор контакта: GET и PUT /dunning/contacts/{contactId}/profile. Тексты ступеней с неформальными версиями (…Informal). Права dunning:read и dunning:write.

v1.173.0 · 18 октября 2026 г.

  • Новое: событие subscriptions.subscription.ended, когда подписка действительно завершилась: на следующий день после последнего оплаченного дня, при любом пути (расторжение, запланированное окончание, смена подписки, исчерпанный срок), один раз на каждое окончание. Данные subscription, endedAt (начало дня после последнего оплаченного дня) и reason (cancelled или completed). Предназначено для «закрыть доступ»; оно привязано к окончанию, а не к расторжению. Кроме того, subscriptions.subscription.cancelled теперь сообщает и о запланированном окончании договора (маркетплейс к концу срока); там status остаётся ACTIVE до окончания, решающим является cancelEffectiveDate.

v1.172.0 · 18 октября 2026 г.

  • Новое: подписки. GET /subscriptions (фильтры status, contactId, due), GET и PATCH /subscriptions/{id} (autoSend, ownDirectDebitOffered), POST /subscriptions/{id}/pause, /resume и /cancel (к концу последнего выставленного периода, без возврата), PUT /subscriptions/{id}/payment-method (закрепить платёжное средство Stripe или перейти на банковский перевод значением null; для MOLLIE это прекращает мандат, mandateOutcome) и POST /subscriptions/generate-due (создать последующие счета к выставлению сейчас). Новые события subscriptions.subscription.paused, .resumed и .cancelled (в том числе при расторжении в клиентском портале), также как триггеры автоматизаций. Права subscriptions:read и subscriptions:write.

v1.171.1 · 18 октября 2026 г.

  • Хуки доступа теперь принимают только публичные адреса https: без учётных данных в адресе, без внутреннего имени хоста, без частного IP-адреса, в том числе после разрешения DNS. Иначе POST /checkout/hooks, PATCH /checkout/hooks/{id} и POST /checkout/hooks/{id}/test отвечают 422 validation-failed с url-not-allowed (или dns-failed, если имя не разрешается). Доставка идёт без перенаправлений и только на адрес, проверенный при подключении.

v1.171.0 · 18 октября 2026 г.

  • Новое: хуки доступа для выставления счетов. Хук уведомляет внешнюю систему о платежах (onIntentSucceeded, onPaymentCompleted, onPaymentFailed), например чтобы открыть или закрыть доступ к курсу. GET и POST /checkout/hooks, GET, PATCH и DELETE /checkout/hooks/{id}, POST /checkout/hooks/{id}/rotate-secret, DELETE /checkout/hooks/{id}/secret, POST /checkout/hooks/{id}/reactivate и POST /checkout/hooks/{id}/test (202). Секрет возвращается, только если его создаёт claritos (generateSecret при создании, rotate-secret без собственного), и только в этом ответе; в остальных случаях есть hasSecret. Назначение по целям: GET и PUT /checkout/hook-assignments/{targetType}/{targetId} с checkout-link, article, quote или order. Управление требует пользователя с ролью ORG_ADMIN (no-acting-user или forbidden), чтение и назначение — нет.

v1.170.0 · 18 октября 2026 г.

  • Новое: коды скидок для оформления заказа. GET и POST /checkout/discount-codes, GET, PATCH и DELETE /checkout/discount-codes/{id}: скидка в процентах (PERCENT, percent) или фиксированная в центах (FIXED, amountCents), по желанию срок действия, максимальное число применений, партнёр и привязка к отдельным ссылкам на оплату (checkoutLinkIds, пусто = все). Без code claritos создаёт читаемый код, при желании с codePrefix. Фильтр code показывает, занят ли код, checkoutLinkId — коды, действующие для ссылки. Применённый код нельзя удалить (409 conflict с redeemed; тогда active: false). Права checkout:read и checkout:write.

v1.169.0 · 18 октября 2026 г.

  • Новое: ссылки на оплату. GET и POST /checkout-links, GET, PATCH и DELETE /checkout-links/{id}: ссылки с артикулом, ценой в центах, целевой аудиторией, запрашиваемыми данными, платёжным провайдером (STRIPE или MOLLIE), собственным прямым дебетованием, дополнительными предложениями (bumps), планами оплаты (plans) и предложениями после покупки (upsells); при записи списки заменяют существующие. Удалить можно только ссылку без счетов (иначе 409 conflict с has-invoices; тогда active: false). POST /checkout-links/{id}/personal-links создаёт персональную ссылку для контакта, действующую семь дней. GET и PATCH /checkout/settings: стандартный составитель счетов организации. Права checkout:read и checkout:write; только организации BUSINESS и HOLDING.

v1.168.0 · 18 октября 2026 г.

  • Новые права для выставления счетов: checkout:read/checkout:write (ссылки на оплату, коды скидок, персональные ссылки, хуки доступа), subscriptions:read/subscriptions:write (подписки), credits:read/credits:write (программа кредитов) и dunning:write (напоминания об оплате). Они подготовлены для адресов, которые появятся позже; до тех пор они не дают доступа. Существующие ключи и доступы OAuth не получают их автоматически.

v1.167.0 · 17 октября 2026 г.

  • Новое: настройки live-комнаты claritos. У типа встречи liveRoom с classId (класс для сессионных комнат по подгруппам) и summarizeBreakouts, в POST /appointment-types и PATCH /appointment-types/{id} и в каждом ответе с типом встречи. У встречи GET и PUT /appointments/{id}/live-room: переопределить класс, запись и резюме сессионных комнат или вернуть к типу встречи значением TYPE, а также что действует (effective).

v1.166.1 · 16 октября 2026 г.

  • API-MCP (/api/mcp/v1, /api/mcp/v1/compact, а также /o/{orgId}): GET теперь отвечает 405 Method Not Allowed с Allow: POST, OPTIONS. Сервер работает без состояния и сам ничего не отправляет; раньше GET открывал поток, который оставался открытым до истечения лимита времени. MCP-клиенты, как и предусмотрено, считают 405 признаком отсутствия потока и продолжают работу через POST. Без доступа по-прежнему 401 с WWW-Authenticate.

v1.166.0 · 15 октября 2026 г.

  • Новое: check.overallScore — общий спам-балл рассылки в процентах (от 0 до 100, null без проверки): техника из баллов Rspamd по его порогам (4 балла 25 %, 6 баллов 50 %, 15 баллов 100 %, между ними линейно) и содержание из проверки ИИ, объединённые как 1 − (1 − техника)(1 − содержание), при двух версиях — худшая. Новое в spamReports[].report.symbols[].origin: testSend для правил, которые возникают только из-за тестовой отправки в claritos; в общем балле они не учитываются. Поведение: красные замечания больше не блокируют запуск. POST /email-campaigns/{id}/start требует confirmWarnings: true как при жёлтых, так и при красных замечаниях (иначе 422 precondition-failed с campaign-check-warnings); campaign-check-red больше не возникает. Запланированная рассылка приостанавливается перед сроком, только если содержание изменилось после проверки и новая проверка содержит замечания.

v1.165.1 · 15 октября 2026 г.

  • Текст: в GET /email-campaigns/setup подгруппа класса теперь называется в smartLists[].name «Класс › Группа», чтобы одноимённые группы разных классов можно было различить. Идентификатор и получатели не меняются.

v1.165.0 · 15 октября 2026 г.

  • Новое: собранные списки (например, классы) в /contact-lists. Список состоит из отдельно выбранных контактов-лиц и делится на именованные подгруппы; каждое лицо входит не более чем в одну подгруппу. GET /contact-lists (постранично, с memberCount и подгруппами), GET /contact-lists/{id} (подгруппы с contactIds, а также withoutSubgroup), POST, PATCH, DELETE /contact-lists/{id}; подгруппы через POST /contact-lists/{id}/subgroups, PATCH/DELETE /contact-lists/{id}/subgroups/{subgroupId} и PUT /contact-lists/{id}/subgroups/order; участники через POST /contact-lists/{id}/members (с subgroupId), POST /contact-lists/{id}/members/from-selection (tags, smartListIds), PUT /contact-lists/{id}/members/subgroup и POST /contact-lists/{id}/members/remove. Для чтения нужно contacts:read; изменять могут автор списка или ORG_ADMIN (иначе forbidden, без действующего лица no-acting-user). Причины: 409 conflict с subgroup-name-taken, 422 precondition-failed с too-many (более 2000 участников или 100 подгрупп). Компании не становятся участниками (notPerson).

v1.164.0 · 15 октября 2026 г.

  • Новое: check.contentReports для каждой версии, отчёт проверки содержания с помощью ИИ: score (от 0 до 100, не процент), zone (none, low, elevated, high) и findings с category, strength (slight, clear, strong) и quote (дословно из темы или текста). Оценку claritos рассчитывает по находкам по фиксированной схеме. Новое в check.findings[].rule: kiRisiko (yellow, начиная с elevated, value = оценка) и kiGering (info, value = оценка); правила от kiGewinn до kiUnserioes из 1.162.0 больше не создаются, в старых проверках они остаются. Также новое в быстрой проверке: betreffAntwort (yellow, тема начинается с «Re:» или «Fwd:») и linkTextTaeuscht (yellow, текст ссылки называет другой домен, чем её цель).

v1.163.0 · 15 октября 2026 г.

  • Новое: GET и PUT /organization/security-txt читают и задают адрес для сообщений об уязвимостях (email). Если он задан, собственные домены организации отдают /.well-known/security.txt по RFC 9116; null удаляет его. Задать может только лицо с ролью ORG_ADMIN, недопустимый адрес даёт 422.

v1.162.0 · 14 октября 2026 г.

  • Новое: семь значений для check.findings[].rule рассылок. kiGewinn, kiGesundheit, kiDruck, kiUebertreibung и kiUnserioes (всегда level yellow, value — цитата из текста) сообщают об обещаниях денег или воздействия на здоровье, давлении, преувеличениях и непрофессиональных формулировках, которые нашла проверка содержания с помощью ИИ в теме или тексте шаблона; kiOk и kiFehler (info) сообщают, что она ничего не нашла или не выполнялась. В продакшене только после того, как это будет указано в политике конфиденциальности; до тех пор этих значений там нет.

v1.161.0 · 14 октября 2026 г.

  • Новое: «Мои почтовые ящики». GET /mailboxes/mine перечисляет ящики, которые может открыть действующее лицо (personal и общие с доступом). GET /mailboxes/{key}/messages показывает папку (inbox, sent, archive, spam, trash), GET /mailboxes/{key}/messages/{folder}/{uid} читает письмо, POST /mailboxes/{key}/messages/update ставит отметки, перемещает или убирает из ящика. POST /mailboxes/attachments выдаёт подписанный адрес для вложения, POST /mailboxes/{key}/send отправляет из этого ящика (личного или общего) через учётную запись SendGrid организации, с записью в исходящих. Причины при 422 precondition-failed: invalid-recipients, attachment-not-uploaded, send-failed.

v1.160.0 · 14 октября 2026 г.

  • Поведение, спецификация без изменений: письма из почтовых ящиков, которые пользователь за доступом не может видеть (правило из GET /mailboxes), теперь отсутствуют в GET /inbox/threads и других эндпоинтах входящих, в переписке с контактом (/contacts/{id}/conversation, включая ящики, запись и ответ) и в исходящих (GET /outbound-emails, GET /outbound-emails/{id}, POST /outbound-emails/{id}/resend). Цепочка без видимого сообщения и такая запись считаются несуществующими (404). Ключ без действующего пользователя видит только ящики, открытые всем ролям. Без ограниченных ящиков ничего не меняется.

v1.159.0 · 14 октября 2026 г.

  • Новое: почтовые ящики. GET /mailboxes перечисляет личные и общие ящики на домене для личных писем с адресом и правилом доступа (access.roles, access.rolesWithRecordAccess, access.users); POST /mailboxes, PATCH /mailboxes/{id} и DELETE /mailboxes/{id} создают, меняют и удаляют общие ящики, например info@ (только ORG_ADMIN). GET /mailboxes/personal/me показывает собственный личный ящик, PUT /mailboxes/personal/{userId}/access задаёт, кто видит его письма (свой может каждый, чужой только ORG_ADMIN). Причины при 422 precondition-failed: no-personal-domain, invalid-local-part, display-name-required, not-a-member; занятый адрес даёт 409 conflict с address-taken. Правило начнёт действовать для входящих, исходящих и переписки в одной из следующих версий; до тех пор все видят всё, как прежде.
  • Текст: mood у цепочек входящих теперь описывает тон последнего классифицированного входящего письма, а не только ответа. Классифицироваться будет каждое настоящее письмо, кроме спама и рассылок (в продакшене только после того, как это будет указано в политике конфиденциальности).

v1.158.0 · 13 октября 2026 г.

  • POST /organization/invitations принимает deliverTo: если email относится к домену личной почты организации, почтовый ящик появляется только после принятия; приглашение тогда уходит на deliverTo (обязательно, иначе 422 у поля), а имя до @ должно быть свободно (409 conflict, reason: mailbox-taken). Приглашения содержат deliveredTo (иначе null).

v1.157.0 · 13 октября 2026 г.

  • Поведение, спецификация без изменений: записи, которые кто-то создаёт на календарном устройстве (Thunderbird, iPhone, CalDAV), теперь являются личными встречами человека, а не отсутствиями, если только их категория не отпуск, больничный, обучение или отсутствие. Поэтому отсутствия ресурса (GET /appointment-resources/{id}) больше не включают личные встречи; они по-прежнему блокируют время (если не отмечены как свободные). Изменение личной встречи через PUT /appointment-resources/{id}/absences/{absenceId} превращает её в отсутствие.

v1.156.0 · 13 октября 2026 г.

  • Новое: projectId в POST /appointments. Типы приёма с оплатой QUOTA теперь можно назначать изнутри (правило владельца: снаружи их по-прежнему записывает только клиент в портале). Тогда обязателен проект клиента, свободного бюджета времени которого хватает на длительность; длительность резервируется при создании. Если проекта нет, он не принадлежит клиенту или бюджета не хватает, 400 для body.projectId. Для серии повторяющихся записей, групповой записи или серии этапов API отвечает 422 с precondition-failed и причиной quota-single-only (раньше quota-portal-only, она остаётся для ссылок записи).

v1.155.0 · 13 октября 2026 г.

  • GET/PATCH /organization/letterhead содержат cancellationRefundDays: срок в днях (от 0 до 365), который сторнирующий счёт указывает для возврата уже оплаченного счёта. Значение по умолчанию диалога сторно; вне диапазона 422 у поля.

v1.154.0 · 13 октября 2026 г.

  • Сторнирующие счета (kind: CANCELLATION), в том числе через POST /invoices/{id}/cancel: меняется только поведение, поля остаются. Новый сторнирующий счёт имеет bankTransferEnabled: false вместо значения исходного счёта. paymentTermsText содержит фиксированное предложение на языке и с обращением счёта: если счёт ещё не был оплачен, что ничего делать не нужно; иначе до какого дня будет возвращена уплаченная сумма. Открытая позиция возврата клиенту наступает в этот день, а не сразу. Срок берётся из настройки организации (14 дней, если ничего не задано); параметра у адреса для этого нет. Более ранние сторнирующие счета не меняются.

v1.153.0 · 13 октября 2026 г.

  • finAPI: PUT /finapi/accounts/{externalAccountId}/connection возвращает precondition-failed с reason: finapi-terms-consent, пока организация не приняла п. 5 § 11 Условий использования (подключение банка через finAPI). Это касается только клиентов, заключивших договор до 13.10.2026, до вступления изменения в силу для них (FI.134). Согласие даётся в claritos при подключении банка (setupUrl из GET /finapi); API согласие не принимает.

v1.152.0 · 13 октября 2026 г.

  • Новый GET /documents/{id}/related (право documents:read): связанные документы документа, как в просмотре в разделе «Связанные документы». Каждая запись содержит id, title, mimeType, createdAt и relation: session (документ встречи), recording (запись встречи), split-original/split-part (оригинал и часть разделения), signed (подписанная версия), signing-original (оригинал до подписи), same-email (вложение того же письма), same-appointment (документ той же встречи). Каждый документ один раз; то, что ключу не разрешено видеть, отсутствует (как в GET /documents).

v1.151.0 · 13 октября 2026 г.

  • SendGrid: домен календарей записей может совпадать с доменом личных писем (SV.147). Тогда имена людей и метки ресурсов должны быть уникальны вместе; иначе conflict с reason: address-taken (у PUT /sendgrid/domains/{id}/calendar и PUT /sendgrid/domains/{id}/personal с localParts, у PUT /sendgrid/my-sender-name без). Причины sendgrid-domain-is-personal и sendgrid-domain-is-calendar больше не возникают.
  • SendGrid: поле automaticSecurity у каждого домена, receiveOnDomain при создании (POST /sendgrid/domains) и новая точка POST /sendgrid/domains/{id}/recreate (SV.148). Домен личных писем и календарей записей принимает почту на себя; ответы идут на тот же адрес, с которого написано письмо. В SendGrid это возможно только без «Automatic Security» (записи MX и TXT вместо CNAME; у MX-записей есть priority), иначе precondition-failed с reason: sendgrid-domain-automatic-security.
  • SendGrid: POST /sendgrid/domains/{id}/replies для любого домена (SV.149). Для домена, на котором нет ни личных писем, ни календарей записей, хост лежит под доменом, а ответы, например на рассылки, попадают во входящие организации; рассылки тогда указывают этот адрес для ответа. В production только после того, как это назовёт политика конфиденциальности (precondition-failed, reason: sendgrid-replies-not-released).

v1.150.0 · 12 октября 2026 г.

  • Новое: guests при создании индивидуальной записи (POST /appointments, POST /appointment-recurrences): имя и электронная почта для каждого гостя, не больше maxGuests типа приёма. Гости создаются в той же операции и получают собственное приглашение, где клиент указан как пригласивший; для серии повторяющихся записей также в последующих записях. Если тип приёма не допускает гостей или это групповая запись, 400.

v1.149.0 · 12 октября 2026 г.

  • Новое: accountEmail в подписке на календарь ресурса (/appointment-resources/{id}/calendar-feed): адрес электронной почты его календаря записей (сотрудник, помещение, оборудование), иначе null. Помещения и оборудование сами отвечают на приглашения по этому адресу; где есть календарь записей, письма о записях отправляются с него.

v1.148.0 · 12 октября 2026 г.

  • SendGrid: календарный домен для календарей записей. Поле calendar у каждого домена, calendarAvailable в состоянии (GET /sendgrid) и PUT /sendgrid/domains/{id}/calendar (enabled): не более одного домена на организацию, никогда не домен личных писем, только подтверждённый и без MX, указывающего в другое место. POST /sendgrid/domains/{id}/replies настраивает для этого домена приём на самом домене (host тогда не учитывается). Новые причины для precondition-failed: sendgrid-calendar-not-released, sendgrid-domain-is-personal, sendgrid-domain-is-calendar, sendgrid-domain-foreign-mx, dns-unavailable. Включается только при правах на календари записей и e-mail-рассылки, в production пока нет (calendarAvailable: false).

v1.147.0 · 12 октября 2026 г.

  • Новое: подписка на календарь для каждого ресурса. GET/POST/PATCH/DELETE /appointment-resources/{id}/calendar-feed: состояние, новый секретный адрес ICS (только в ответе POST; прежний перестаёт действовать), имена клиентов вкл. или выкл., завершение. Без права 412 с calendar-feed-not-enabled.

v1.146.0 · 12 октября 2026 г.

  • GET /organization/entitlements знает новое право TERMINKONTEN (фид подписки, CalDAV и собственные адреса для ресурсов). Оно действует только вместе с E_MAIL_KAMPAGNEN; без него effective ложно.

v1.145.0 · 12 октября 2026 г.

  • Новое: переносить приёмы серии, не нарушая цепочку. POST /appointments/{id}/series-proposal сообщает, подходит ли новое время, иначе допустимый период и заново размещённые забронированные следующие шаги; POST /appointments/{id}/reschedule-with-series переносит все по предложению. Изменено: POST /appointments/{id}/reschedule отклоняет время, нарушающее цепочку, с 412 и series-chain-broken (раньше переносил без проверки).

v1.144.0 · 12 октября 2026 г.

  • Новое: GET /appointment-series выдаёт текущие серии с их состоянием (сначала открытые шаги, openStep.passed, ближайший приём), а POST /appointment-series/{id}/cancel-from отменяет приём и все следующие шаги; серия завершается, клиент получает одно уведомление об отмене с перечислением остальных приёмов.

v1.143.0 · 12 октября 2026 г.

  • Новое: клиенты сами начинают серию приёмов. POST /appointment-series-templates/{id}/start-links с contactId возвращает личную ссылку (/t/serie/…), одну на клиента и шаблон; там клиент видит предложение (при STEPWISE только шаг 1) и записывается одним нажатием. Изменено: clientBookable теперь действует и при ADVANCE и сохраняется так, как передано (раньше при ADVANCE сохранялось как false). Без clientBookable 412 с series-not-client-bookable.

v1.142.0 · 12 октября 2026 г.

  • Новое: клиенты сами записываются на следующие шаги серии. Шаблоны принимают и возвращают clientBookable (действует только вместе с bookingMode STEPWISE, при ADVANCE сохраняется как false); серии тоже его возвращают. Когда шаг открывается, клиент получает письмо со ссылкой для записи, которая показывает только время в окне шага, и напоминание перед его окончанием.

v1.141.0 · 12 октября 2026 г.

  • Новое: серии приёмов шаг за шагом. Шаблоны и серии несут bookingMode (ADVANCE как прежде, STEPWISE: сначала только шаг 1, каждый следующий открывается, когда состоялся предыдущий). При STEPWISE POST /appointment-series принимает ровно одну запись (раньше не менее двух); POST /appointment-series/proposal тогда предлагает только шаг 1. GET /appointment-series/{id} дополнительно возвращает contactId, progress и openStep (окно открытого шага). Новые POST /appointment-series/{id}/steps/{step}/proposal (свободное время в окне) и POST /appointment-series/{id}/steps/{step} (бронирует открытый шаг; не открыт 412 с series-step-not-open, вне окна 422 в body.startsAt).

v1.140.0 · 12 октября 2026 г.

  • Новое: серии приёмов (последовательность разных типов приёма с окнами). GET/POST /appointment-series-templates, PATCH /appointment-series-templates/{id} (шаги с appointmentTypeId, durationMinutes, fromDay/toDay после предыдущего шага, samePersonAsStep), POST /appointment-series/proposal (самая ранняя полная последовательность с from, ничего не бронирует; без мест 412 с series-no-slots), POST /appointment-series (заранее, всё или ничего) и GET /appointment-series/{id}.

v1.139.0 · 12 октября 2026 г.

  • Новое: GET /appointments/{id}/waitlist (лист ожидания мероприятия: state WAITING, OFFERED, ACCEPTED, EXPIRED, DECLINED, REMOVED, а также position и offerExpiresAt). Поведение: когда на мероприятии с листом ожидания освобождается место, первый в списке получает предложение со сроком; пока оно действует, место удерживается, в том числе от записи по ссылке.

v1.138.0 · 12 октября 2026 г.

  • Серии приёмов: POST /appointment-recurrences/{id}/change-from (appointmentId, startsAt, rule, end, необязательно длительность, место, услуга, телефон, сотрудник, пропуски): новая серия с нового первого времени с клиентами указанного приёма; он и следующие старые приёмы отменяются; ответ — новая серия. Поведение: при cancel-from и change-from приёмы отменяются без отдельного письма, только если каждый их клиент получает общее письмо; у мероприятий каждый приём получает своё уведомление об отмене.

v1.137.0 · 12 октября 2026 г.

  • Серии приёмов: POST /appointment-recurrences/{id}/end (завершить; созданные приёмы остаются), POST /appointment-recurrences/{id}/cancel-from (appointmentId, необязательно reason: отменить этот и все следующие; клиент получает ОДНО уведомление со списком остальных) и PATCH /appointment-recurrences/{id} (изменить end, например продлить; не раньше созданных приёмов, иначе 422 с too_small). Поведение: подтверждение первого приёма серии называет правило словами.

v1.136.0 · 12 октября 2026 г.

  • Новое: серии приёмов (повторяющиеся приёмы, любой тип приёма). POST /appointment-recurrences создаёт серию: поля первого приёма как у POST /appointments, плюс rule (weekly с интервалом от 1 до 4 и днями со временем, monthlyWeekday с n-м или последним днём недели, monthlyDay), end (count от 2 до 200, until до двух лет, open) и skipHolidays/skipClosures (по умолчанию включено). Расчёт в часовом поясе типа приёма; следующие приёмы создаются в фоновом режиме без отдельного подтверждения. GET /appointment-recurrences/{id} возвращает правило, состояние, предстоящие приёмы и пропущенные с причиной. У приёмов появилось поле recurrenceId. Неверное правило или окончание: 422 для body.rule или body.end.

v1.135.0 · 12 октября 2026 г.

  • События (групповые типы с internalOnly: false, не занятия): POST /appointments для события можно вызывать без participants, тогда приём создаётся со свободными местами; выбор, в котором никого нет, по-прежнему отвечает 422 с too_small. DELETE /appointments/{id}/participants/{contactId} у события исключает и последнего участника (без last-participant). Клиенты записываются на место в созданном приёме по ссылке для записи; /appointment-types/{id}/slots по-прежнему показывает, когда команда может создать приём.

v1.134.0 · 12 октября 2026 г.

  • Типы приёма: новые поля minParticipants, minParticipantsHours, minParticipantsAction (NOTIFY, CANCEL), waitlistEnabled, waitlistOfferHours (чтение и запись; минимум и лист ожидания для групповых типов, лист ожидания только для событий). internalOnly теперь возвращает сохранённое значение для групп: false означает событие (клиенты записываются на место), занятия остаются внутренними. Пакет только для индивидуальных типов (422 с quota_group). Неверные значения: 422 с minimum_invalid, minimum_hours_invalid, waitlist_hours_invalid.

v1.133.0 · 12 октября 2026 г.

  • Встречи из пакета: новое поле quota у встречи (projectId, minutes, state: HELD, CONSUMED, RELEASED; null без пакета) и POST /appointments/{id}/quota/release (причина от 3 до 500 символов) освобождает зарезервированное время с протоколом; без открытого резерва 422 с quota-not-held. После встречи фактическое время Zoom попадает в проект как запись времени, резерв переходит в CONSUMED.

v1.132.0 · 12 октября 2026 г.

  • Встречи из пакета записывает только клиент в портале (правило владельца): POST /appointments с типом приёма в режиме QUOTA теперь отвечает 422 с precondition-failed и причиной quota-portal-only вместо создания встречи без проекта. Отмена (POST /appointments/{id}/cancel) освобождает зарезервированное время проекта; перенос с другой длительностью корректирует резерв.

v1.131.0 · 12 октября 2026 г.

  • Типы приёма в режиме QUOTA (пакет): при записи (POST/PATCH /appointment-types) место теперь только онлайн (places: ["ONLINE"]), оба переключателя Zoom включены (recording.autoRecord, recording.fetchZoomRecordings) независимо от ввода. Состав (PUT /appointment-types/{id}/staffing) такого типа требует meetingProvider: "ZOOM" у каждого сотрудника и не допускает партнёрской роли; иначе 422 с кодом quota_zoom_required или quota_partner. Запись на пакет через портал появится в следующей версии.

v1.130.0 · 12 октября 2026 г.

  • Счета и предложения: новое поле contactEmail (строка или null) — адрес электронной почты связанного контакта; null без контакта или без адреса. В GET /invoices, GET /quotes, отдельных запросах и ответах и в событиях invoices.invoice.* и quotes.quote.*.
  • События payments.checkout.*: новые поля в объекте checkout: checkoutLinkName (название ссылки оплаты, то есть продукт; null без названия), customerName (контакт счёта, иначе имя, указанное при оплате), orderId и orderNumber (заказ счёта, иначе null) и только в payments.checkout.failed — failureReason: direct_debit_failed (прямое дебетование не прошло), chargeback (возврат платежа), no_mandate (нет мандата) или payment_failed (другая причина). Прежние поля сохраняются.

v1.129.0 · 12 октября 2026 г.

  • Задачи: новое поле contactEmail (строка или null) — адрес электронной почты связанного контакта; null без контакта или без адреса. В GET /tasks, GET /tasks/{id}, ответах на создание и изменение и в событиях tasks.task.*. Так процессы без идентификатора контакта находят контакт по адресу.

v1.128.0 · 12 октября 2026 г.

  • API-MCP для языковых моделей: при подключении сервер передаёт обзор claritos (instructions: области по группам с одним предложением и числом адресов, доступных этому доступу, правила, типичные процессы). Новый инструмент guide (обзор, область с её адресами или руководство из /developers). Описания полей инструментов теперь приходят текстом; раньше там стояли ключи перевода вроде apiDocs.fields.common.limit. Новый адрес /api/mcp/v1/compact (для каждой организации /api/mcp/v1/compact/o/{orgId}) с четырьмя инструментами вместо одного на адрес: guide, search_endpoints, describe_endpoint, call_endpoint; тот же вход, права, лимиты и журнал. /api/mcp/v1 и /api/v1 не меняются.

v1.127.0 · 12 октября 2026 г.

  • Новое: GET /call-guides/options (callguides.options, только ORG_ADMIN) за один вызов возвращает всё, что редактор сценариев предлагает для действий и полей: шаблоны (sms, promotional), участники, персональные ссылки на оплату, формы, рекламные материалы, типы встреч с holders и поля контакта (fixed, standard, custom) с вариантами. Идентификаторы и ключи используются в содержимом POST /call-guides и PATCH /call-guides/{id}.

v1.126.0 · 12 октября 2026 г.

  • Новое: чтение звонков (область calls, только чтение, каждый участник). GET /calls выводит звонки от новых к старым (фильтр missed, messages, withoutContact, contactId для владельца номера или собеседника, поиск q, updatedSince), GET /calls/{id} читает один. Поля совпадают с событием calls.call.ended, плюс автоответчик и состояние заметки о разговоре. Заметка (note) и автоматическая заметка (callNote) — данные клиентов: их текст только с разрешения организации и правом clients:, иначе null с hasNote/hasCallNote.

v1.125.0 · 12 октября 2026 г.

  • Письма: POST /letters/{id}/finalize (зафиксировать без отправки), POST /letters/{id}/duplicate (копия как черновик), DELETE /letters/{id} (не после присвоения номера, 409 numbered-no-delete), POST /letters/{id}/cancel-signature (отменить идущую подпись, 409 signature-completed после завершения) и POST /letters/{id}/number (присвоить порядковый номер, 202, PDF создаётся заново). Исходящие: POST /outbound-emails/{id}/resend отправляет письмо повторно, при желании на другой адрес или с изменённым текстом, с собственной записью; не для кодов, скрытых данных, кампаний и анонимизированных записей (409 not-resendable).
  • Выданные документы из PDF-шаблонов (сертификаты): GET /issued-documents, GET /issued-documents/{id}, POST /issued-documents, DELETE /issued-documents/{id} (только черновики), POST /issued-documents/{id}/finalize, POST /issued-documents/{id}/retry-file, POST /issued-documents/{id}/cancel (только ORG_ADMIN) и POST /issued-documents/{id}/letter (подготовить письмо с документом во вложении). Выдавать могут те, кто пишет письма (ORG_ADMIN, ORG_USER), как в приложении.
  • Входящие: GET /inbox/threads, GET /inbox/threads/{id}, PATCH /inbox/threads/{id} (прочитано, в архиве, ответственный, контакт, теги), GET /inbox/tags, GET /inbox/counts и POST /inbox/threads/{id}/task (задача из ветки, дополнительно нужно tasks:write). Вложения как идентификаторы документов (documents.downloadUrl). Ветки контакта с клиентской картой только при разрешении данных клиентов и clients:read.
  • Переписка с контактом: GET /contacts/{id}/conversation (история по e-mail, SMS, сообщениям в портале и в карте, звонкам), GET /contacts/{id}/conversation/{source}/{entryId} и …/reply-basis, GET /contacts/{id}/conversation/compose (отправители, шаблоны, разрешение), GET /contacts/{id}/conversation/permission, POST /contacts/{id}/conversation/email, POST /contacts/{id}/conversation/portal-post (clients:write), POST /contacts/{id}/conversation/sms и POST /contacts/{id}/conversation/sms-preview. Чтение ничего не отмечает как прочитанное; рекламные только с согласием. Новая причина для precondition-failed: client-record-missing.

v1.124.0 · 12 октября 2026 г.

  • Типы приёма: новое поле startWindows (чтение и запись в POST/PATCH /appointment-types): когда может начинаться приём этого типа, в каждой записи days (1 = понедельник … 7 = воскресенье), earliest и latest (HH:MM в часовом поясе типа приёма, включительно), не более 14; null или [] снимает ограничение. /appointment-types/{id}/slots предлагает тогда только время внутри них, запись и перенос клиентом соблюдают их. Неверно: 422 с путём body.startWindows.

v1.123.0 · 12 октября 2026 г.

  • Логотипы и тип организации: GET /organization/logos, POST /organization/logos/{kind}/upload (проверка формата и размера, подписанный адрес для прямой загрузки), POST /organization/logos/{kind}/confirm и DELETE /organization/logos/{kind}, для logo и invoice-logo; для SVG и WebP, как в приложении, создаётся PNG-версия для писем. PATCH /organization дополнительно принимает type (BUSINESS, HOUSEHOLD, HOLDING); частная организация сохраняет свой тип (409 conflict, reason: private-organization). Изменение с organization:write и лицом с ролью ORG_ADMIN.

v1.122.0 · 12 октября 2026 г.

  • Гости индивидуального приёма: POST /appointments/{id}/guests (имя, e-mail) приглашает гостя от имени записавшегося, DELETE /appointments/{id}/guests/{contactId} отзывает приглашение (гость получает «Приглашение отозвано», приём остаётся). Право appointments:write и лицо с правом «Управление расписанием». Новое поле isGuest у participants. Новые причины для precondition-failed: group-appointment-has-no-guests, guest-limit-reached.

v1.121.0 · 12 октября 2026 г.

  • Подключения, интеграции и собственные домены организации: GET /organization/entitlements (каждое право с лицензией, разрешением и действием), GET /organization/integrations (состояние каждого подключения со страницей для подключения; LeadConnector называется там leadconnector), GET/POST /organization/domains, POST /organization/domains/{purpose}/verify и DELETE /organization/domains/{purpose} (назначение app, finder, marketplace; ответ называет недостающие DNS-записи). Всё лицом с ролью ORG_ADMIN; собственные домены требуют разрешения claritos, чужой домен отвечает 409 conflict с reason: taken.

v1.120.0 · 12 октября 2026 г.

  • Документы: каждый документ содержит extracted.counterpartyDetails (адрес с street, postalCode, city, country в виде ISO-кода, а также email, phone, website и contactPerson с name, email, phone, position), как ИИ прочитал их из документа; null, если ничего не распознано. Новый POST /documents/{id}/counterparty-contact (права documents:write и contacts:write): связывает документ с контактом его контрагента, как «Создать контакт» в приложении. Уже связанный контакт остаётся; иначе контакт с точно таким именем, подходящая компания (ИНН/НДС, регистр, домен, имя) или новый с адресом. Ответ { contactId, created }; без контрагента 409 conflict с reason: no-counterparty.

v1.119.0 · 12 октября 2026 г.

  • Новое: чтение входящих SMS. GET /inbound-sms выводит SMS, отправленные на номер организации (от новых к старым, страницы как у GET /sms, фильтр contactId, updatedSince здесь означает «получено с»), с контактом, способом сопоставления (number, personBeforeCompany, ambiguous, unknown, manual) и ключевым словом отписки Twilio; GET /inbound-sms/{id} читает одно. Область sms, право sms:read.

v1.118.0 · 12 октября 2026 г.

  • Обращение и правовые тексты организации: GET/PATCH /organization/salutation (на «вы» или на «ты» по умолчанию, «ты» для отдельных контактов, «вы» обязательно по типу документа, приветствие), GET/PATCH /organization/legal-texts (все правовые тексты вместе со стандартными, ответственный за защиту данных и надзорный орган), PUT/DELETE /organization/legal-texts/{kind} (задать собственный текст, версия растёт; вернуть стандартный). Чтение с organization:read, изменение с organization:write и лицом с ролью ORG_ADMIN. У частной организации нет правовых текстов (403 feature-not-available).

v1.117.0 · 12 октября 2026 г.

  • Контакты, часы работы и бланк организации: GET/PATCH /organization/contact (адрес для посещения, телефон, e-mail для сайта и портала), GET/PUT /organization/opening-hours (до двух интервалов на день недели) и GET/PATCH /organization/letterhead (деловая документация: юридическое название, правовая форма, адрес, налоговые и регистрационные данные, руководство, банк, форма бланка, артикулы для учёта времени и возвратных списаний). Чтение с organization:read, изменение с organization:write и лицом с ролью ORG_ADMIN; PATCH меняет только переданное, проверка как в настройках (422 с полем).

v1.116.0 · 12 октября 2026 г.

  • Только представление, ни один адрес не изменён: спецификация группирует области (x-tagGroups, например «Контакты и клиенты», «Продажи и счета»). Каждый тег несёт отображаемое имя (x-displayName) и в описании одно предложение о назначении области. Сами имена тегов (contacts, invoices …) остаются прежними.

v1.115.0 · 12 октября 2026 г.

  • Типы приёма: новое поле maxGuests (чтение и запись в POST/PATCH /appointment-types): сколько ещё человек может пригласить записавшийся на свой приём, от 0 до 20, только при одном месте (иначе всегда 0). Неверное значение: 422 с кодом guests_invalid.

v1.114.0 · 12 октября 2026 г.

  • Запись участников и приглашений (право members:write, лицо с ролью ORG_ADMIN, как во вкладке «Участники»): PATCH /organization/members/{userId} (роль ORG_ADMIN/ORG_USER, видимость, доступ к картам клиентов, языки перевода), DELETE /organization/members/{userId}, POST /organization/invitations (приглашение по e-mail, ссылка действует семь дней) и DELETE /organization/invitations/{id}. Действующее лицо никогда не меняет и не удаляет само себя (403 forbidden, reason: self), последний ORG_ADMIN остаётся (409 conflict, reason: last-admin); уже участник или уже приглашён отвечает 409 conflict с reason: already-member или already-invited.

v1.113.0 · 12 октября 2026 г.

  • Почтовые аккаунты через API (область letters): GET /postal-account (через какого провайдера отправляет очередь, его баланс, пауза, ожидающие письма; ORG_ADMIN дополнительно видит LetterXpress и Pingen подробно в accounts) и POST /postal-account/resume-queue (снять паузу, отправить ожидающие письма, 202). LetterXpress и Pingen подключаются и отключаются только в приложении; их данные доступа API не принимает.

v1.112.0 · 12 октября 2026 г.

  • Чтение наборов данных Meta: GET /organization/meta-datasets (пиксель и Conversions API: название, идентификатор пикселя, тестовый код, hasToken), с organization:read и лицом с ролью ORG_ADMIN. API никогда не выдаёт токен; создание и изменение остаются в приложении, как у SendGrid.

v1.111.0 · 12 октября 2026 г.

  • Брендборд через API (область sites): борды с GET/POST /sites/brands, GET/PATCH/DELETE /sites/brands/{id}, POST /sites/brands/{id}/default и POST /sites/brands/{id}/publish; шрифты с GET/POST /sites/brands/{id}/fonts (собственный шрифт, адрес для загрузки), POST /sites/brands/{id}/fonts/google (импорт шрифта Google, поиск через GET /sites/google-fonts) и DELETE /sites/brands/{id}/fonts/{fontId}; логотипы с GET /sites/brands/{id}/logos, POST/DELETE /sites/brands/{id}/logos/{slot}. PATCH изменяет только переданное (объекты объединяются). Чтение с sites:read, запись с sites:write и лицом с ролью ORG_ADMIN (как в брендборде). Последний борд удалить нельзя (409, last-board); уже импортированный шрифт отвечает 409 с font-already-imported. ИИ-советники брендборда остаются в приложении.

v1.110.0 · 12 октября 2026 г.

  • Банковские подключения (право banking): GET /bank-connections и GET /bank-connections/{id} (для WISE с открытым ключом), POST /bank-connections/{id}/sync (получить выписки), GET /revolut (состояние настройки с адресом в claritos), GET /revolut/accounts и PUT /revolut/accounts/{externalAccountId}/connection (подключить счёт разрешённого доступа), GET /finapi, PUT /finapi/accounts/{externalAccountId}/connection и POST /finapi/banks/{bankConnection}/refresh. Подключение с ключом, вход в Revolut или finAPI и отключение остаются в claritos; ни ключи, ни вход в банк через API не передаются.

v1.109.0 · 12 октября 2026 г.

  • Новое: настройка телефонии и отправителя SMS (область telephony, только ORG_ADMIN). GET /telephony показывает аккаунт, голосовой канал, все номера и настройки активных; POST /telephony/setup настраивает голосовой канал; POST /telephony/numbers активирует номер (с уточнением activated: false, если там уже стоит другая система, подтверждение через overwrite: true); GET/PATCH/DELETE /telephony/numbers/{id} читают, изменяют (строго, заметка о разговоре только с callNotesNoticeConfirmed: true) и отключают; приветствие через POST /telephony/numbers/{id}/greeting/upload, PUT и DELETE /telephony/numbers/{id}/greeting. Twilio: GET /telephony/twilio, GET /telephony/twilio/numbers, PUT /telephony/twilio/sender, POST /telephony/twilio/inbound. Аккаунт Twilio подключается и отключается только в интерфейсе (settingsUrl); чужие адреса на номере API называет только хостом.

v1.108.0 · 12 октября 2026 г.

  • Настройки партнёрской программы организации через API (область affiliates): промокоды с GET/POST /affiliate-coupons, GET/PATCH/DELETE /affiliate-coupons/{id} (включение и выключение через active), отслеживание атрибуции с GET /affiliate-tracking (адрес вебхука конверсий, учётные данные только в замаскированном виде) и DELETE /affiliate-tracking/webhook (отключить), климатический взнос с GET/PUT /affiliate-climate-contribution (0, 50, 100 или 150 базисных пунктов). Чтение с affiliates:read, запись с affiliates:write и лицом с ролью ORG_ADMIN (как во вкладке). Учётные данные вебхука конверсий API не создаёт и не показывает: это возможно только в приложении. Уже занятый промокод отвечает 409 с причиной coupon-code-taken.

v1.107.0 · 12 октября 2026 г.

  • Резервное копирование и журнал согласий организации: GET /backups (настройки и последние 20 запусков), PATCH /backups/settings (интервал, объём, получатели), POST /backups/runs (запустить копирование, 202 с запуском), GET /backups/runs/{id} и PUT /backups/password (установить пароль архива или удалить его через null; он никогда не выдаётся). Кроме того GET /consent-log, GET /consent-log/summary и GET /consent-log/export (CSV), только чтение. Права backups:read/backups:write и consentlog:read, всё только для лица с ролью ORG_ADMIN, как во вкладке. Новые причины для precondition-failed: backup-running и backup-recipients-required.

v1.106.0 · 12 октября 2026 г.

  • Изменение организации: PATCH /organization (право organization:write, лицо с ролью ORG_ADMIN, как в настройках) для названия, основной валюты, страны, режима цен, профиля практики, отрасли, адреса входящих (inboxSlug), псевдонима для ответов (replyAlias) и подписи e-mail; всё или ничего, те же проверки, что и в приложении. Неверные данные отвечают 422 с полем и кодом, занятый адрес входящих или псевдоним 409 conflict с reason: taken, профиль практики без модуля «Практика» 403 feature-not-available. GET /organization дополнительно возвращает inboxSlug, replyAlias, replyAddress, industryCode, defaultPriceMode и emailSignatureHtml.

v1.105.0 · 12 октября 2026 г.

  • Почтовый ящик писем о записях: GET /appointment-mailbox (подключённый ящик Gmail, состояние, адрес для ответов; любой участник) и DELETE /appointment-mailbox (отключить, с правом «Управление расписанием»; письма о записях продолжают уходить с адресом из деловых бумаг). Подключение только в claritos (согласие в Google).

v1.104.0 · 12 октября 2026 г.

  • Новые права для настроек организации (эндпоинты появятся в следующих версиях): members:write (участники, роли, приглашения; до сих пор members был только для чтения), backups:read/backups:write (резервные копии), consentlog:read (журнал согласий сайта, только чтение) telephony:read/telephony:write (настройка телефонии и отправителя SMS) и banking:read/banking:write (банковские подключения). Через OAuth первые четыре получает только ORG_ADMIN организации, как и webhooks:manage; banking:read, как и в интерфейсе, доступно каждому участнику.
  • Приложение LeadConnector: три новых триггера платежей, checkout_pending (платёж начат; при SEPA денег ещё нет), checkout_completed (платёж получен) и checkout_failed (не прошёл, возвращён или пропущен взнос), на событиях payments.checkout.*; и действие invoice-issue (провести счёт, invoices:write), ответ которого содержит documents со статусом и адресом PDF и адресом XML ZUGFeRD, пока он создаётся, с pending: xml-not-ready. Интерфейс /api/v1 при этом не меняется.

v1.103.0 · 12 октября 2026 г.

  • Группы приёмов, доступ для партнёров и календари: GET/POST /appointment-groups, GET/PATCH/DELETE /appointment-groups/{id} (несколько типов приёма на одной странице; как во вкладке, чтение тоже только с правом «Управление расписанием»), GET/PUT /appointment-types/{id}/partner-release (видимость в партнёрской программе) и GET /appointment-resources/{id}/calendars (выбранные календари Google ресурса, только чтение; списки календарей аккаунтов Google API не выдаёт). Теперь раздел записей можно полностью настроить через API и MCP.

v1.102.0 · 12 октября 2026 г.

  • Настройка планов напоминаний: GET/POST /appointment-reminder-plans, GET/DELETE /appointment-reminder-plans/{id} (удаление архивирует), POST /appointment-reminder-plans/{id}/steps, PATCH/DELETE /appointment-reminder-steps/{id}, POST /appointment-reminder-steps/{id}/move и POST /appointment-reminder-preview (подставлены примерные значения, названы неизвестные переменные). Список указывает язык текстов и каталог переменных. Чтение с appointments:read, настройка с appointments:write и лицом с ролью ORG_ADMIN (как во вкладке). Текст с неизвестной переменной отвечает 422 с кодом unknown_variable.

v1.101.0 · 12 октября 2026 г.

  • Настройка закрытий и мест: GET/POST /appointment-closures, PATCH/DELETE /appointment-closures/{id} (праздник, день-мост, корпоративные каникулы, прочее; на целый день или с временным окном; affectedAppointments считает существующие приёмы в периоде, они остаются), PUT /appointment-bridge-day-rule (закрыто во все дни-мосты), POST /appointment-closures/{id}/keep-open и DELETE /appointment-bridge-day-rule/kept-open/{date} (оставить день-мост открытым или снова закрыть), GET /appointment-places, POST/PATCH/DELETE /appointment-phones[/{id}], POST/PATCH/DELETE /appointment-venues[/{id}] и PUT /appointment-venues/{id}/groups (помещения и оборудование, которые должны быть свободны по адресу). Чтение с appointments:read, запись с appointments:write и правом «Управление расписанием». Удаление номера или адреса, который ещё выбран, отвечает 409 с in-use. Новая причина для precondition-failed: closure-automatic.

v1.100.0 · 12 октября 2026 г.

  • Настройка SendGrid через API (область campaigns): GET /sendgrid (право, подключение, недостающие права ключа, уведомления и по каждому домену отправителя DNS-записи, DMARC, личные письма, ответы), POST /sendgrid/events, POST /sendgrid/domains (возвращает DNS-записи, которые нужно задать), POST /sendgrid/domains/{id}/verify, DELETE /sendgrid/domains/{id}, PUT /sendgrid/domains/{id}/personal, POST/DELETE /sendgrid/domains/{id}/replies и POST /sendgrid/domains/{id}/replies/verify (ответы через Inbound Parse, MX-запись в replies.mxRecord), а также GET/PUT /sendgrid/my-sender-name (собственное имя до @, для каждого участника). Ключ SendGrid API не принимает: подключение и отключение только в приложении. Всё по организации требует ORG_ADMIN; настройка дополнительно — права «E-mail-кампании», просмотр и удаление работают и без него. Новые причины в 422 precondition-failed: sendgrid-domain-not-in-account, sendgrid-key-invalid, sendgrid-unreachable, sendgrid-rejected, sendgrid-events-failed, sendgrid-personal-not-released, sendgrid-domain-not-confirmed, sendgrid-domain-not-personal, sendgrid-parse-scopes-missing (с missingScopes), replies-not-configured, sendgrid-policy-forbidden, sendgrid-parse-failed, sendgrid-replies-not-set-up.

v1.99.0 · 12 октября 2026 г.

  • Запись автоматизаций (право automations:write, действующее лицо ORG_ADMIN): POST /automations (создаётся выключенным), PATCH /automations/{id} (отсутствующее остаётся, новая версия), DELETE /automations/{id}, POST …/activate и POST …/deactivate, а также POST /automation-runs/{id}/resume для неудачных запусков. Ошибки сценария приходят как 422 validation-failed с местом (body.flow.nodes.‹узел›.fields.‹поле›) и кодом. Новое для чтения: GET /automation-catalog с триггерами (фильтры, подстановки), источниками дат и действиями с их полями.

v1.98.0 · 12 октября 2026 г.

  • Настройка ресурсов: POST /appointment-resources и PATCH /appointment-resources/{id} (та же проверка, что в диалоге ресурса), GET …/availability, PUT …/schedule (график в цикле от 1 до 4 недель), POST …/absences, а также PUT и DELETE …/absences/{absenceId} (отпуск, обучение, болезнь, дополнительный приём), GET и POST …/closure-overrides, а также DELETE …/closure-overrides/{overrideId} (всё же работать в закрытый день), GET …/working-hours (предпросмотр ближайших недель), GET и PUT …/meeting-defaults (пользователь Zoom, собственный номер) и GET …/zoom-users. Права как в приложении: тот, кто управляет записями, — для любого ресурса; человек — для собственного (только часовой пояс, не название, метка и активность; как пользователя Zoom только со своим адресом); собственную доступность создаёт каждый участник. Человек, который уже является ресурсом, отвечает 409 с already-resource. Новая причина для precondition-failed: zoom-unavailable.

v1.97.0 · 12 октября 2026 г.

  • Новое: чтение автоматизаций (область automations, право automations:read): GET /automations, GET /automations/{id} со сценарием (flow: узлы с kind и next, условия, ожидания; действие называется как его эндпоинт, например tasks.create), GET /automations/{id}/runs (последние 100 запусков с шагами, failedOnly) и GET /automations/{id}/stats (90 дней, по каждому узлу: достигнуто, неудачно, выходы, ожидают). Создание и изменение последуют.

v1.96.0 · 12 октября 2026 г.

  • Настройка типов приёма: POST /appointment-types и PATCH /appointment-types/{id} (та же проверка, что в диалоге типа приёма; PATCH меняет только переданные поля), GET и PUT /appointment-types/{id}/staffing (состав: роли, кандидаты, распределение, присутствие, видеоинструмент для каждого), GET и POST /appointment-types/{id}/links, а также POST /appointment-links/{id}/revoke (ссылки записи). Чтение с appointments:read, запись с appointments:write и лицом с правом «Управление расписанием». Занятое краткое имя отвечает 409 с slug-taken. Новые причины для precondition-failed: appointment-type-not-public, quota-portal-only.

v1.95.0 · 12 октября 2026 г.

  • E-mail-кампании через API (область campaigns, путь /email-campaigns, потому что /campaigns — партнёрские кампании): GET /email-campaigns/setup (подключение SendGrid, уведомления, подтверждённые домены, рекламные шаблоны, смарт-списки, теги, собственные адреса для тестового письма), GET/POST /email-campaigns, GET/PATCH/DELETE /email-campaigns/{id}, POST /email-campaigns/recipient-count, POST /email-campaigns/{id}/check (проверка с Rspamd и тестовой отправкой в фоне, 202), POST /email-campaigns/{id}/test-email (только на собственные адреса действующего лица, не более десяти в час, иначе 429), POST /email-campaigns/{id}/start (сразу или с scheduledAt; жёлтый только с confirmWarnings), а также /pause, /resume, /cancel. Каждый эндпоинт, включая чтение, требует ORG_ADMIN (403 forbidden, ключ без создателя — 403 no-acting-user) и права организации «E-mail-кампании» (403 feature-not-available). Новые причины в 422 precondition-failed: campaign-check-missing, campaign-check-outdated, campaign-check-red, campaign-check-warnings, sendgrid-not-connected, sendgrid-events-missing, sendgrid-not-ready, campaign-template-missing, campaign-template-not-marketing, campaign-selection-empty, campaign-smart-list-unknown; переход, который не допускает состояние, отвечает 409 с wrong-status.

v1.94.0 · 12 октября 2026 г.

  • Цели вебхуков полностью через API (право webhooks:manage): POST /webhook-targets (секрет в ответе), PATCH и DELETE /webhook-targets/{id}, POST …/rotate-secret, GET …/secret, POST …/test (синхронно, с примерными данными или контактом; с контактом также contacts:read), GET …/deliveries/{deliveryId}/body (также contacts:read) и POST …/deliveries/{deliveryId}/retry.
  • Новое: входящие хуки через API (/inbound-hooks, право webhooks:manage): список, создание (состояние LEARNING, по желанию с обязательным заголовком Authorization), чтение, изменение (название, recordTypes, mapping, state), удаление, обновление адреса, чтение требуемого заголовка, образец со списком путей (GET …/sample, также contacts:read), доставки, тело доставки (также contacts:read) и повторная обработка.

v1.93.0 · 12 октября 2026 г.

  • Запись приёмов (право appointments:write): POST /appointments (назначить; индивидуальный с contactId, групповой с participants из смарт-списков, тегов и контактов), POST /appointments/{id}/cancel, /reschedule, /host, /type, /no-show, /participants, DELETE /appointments/{id}/participants/{contactId} и POST /appointments/{id}/meeting (обновить видеоссылку). Те же проверки и те же письма, что внутри команды. Каждый из этих вызовов требует лица с правом «Управление расписанием» (владелец, ORG_ADMIN или отдельное право): без лица no-acting-user, без права forbidden. Занятое время отвечает 409 с slot-taken. Новые причины для precondition-failed: contact-without-phone, appointment-not-open, appointment-not-started, not-a-group-appointment, last-participant.

v1.92.0 · 12 октября 2026 г.

  • Нумераторы и PDF-шаблоны в области templates: GET/POST /number-circles, GET/PATCH /number-circles/{id} (префикс, от 6 до 12 разрядов, ежегодный сброс, а также issued и следующий номер; если нумератор выдавал номера, префикс, разрядность и сброс изменить нельзя, 409 с format-locked), GET/POST /pdf-templates, GET/PATCH /pdf-templates/{id} (название, нумератор, срок действия в месяцах, до четырёх мест подписантов) и PUT /pdf-templates/{id}/fields (полный список полей, проверка как в приложении; первая ошибка приходит как 422 validation-failed с причиной в коде, например bindingUnknown или numberWithoutCircle). PDF-шаблон создаётся на PDF, предварительно загруженном и подтверждённом через documents. Запись только если лицо за доступом — ORG_ADMIN. Ни нумератор, ни шаблон не удаляются: active: false выводит из использования.

v1.91.0 · 12 октября 2026 г.

  • OAuth: право webhooks:manage OAuth-доступ теперь получает, только если его пользователь является ORG_ADMIN в привязанной организации, как в интерфейсе. Проверка выполняется при согласии и при каждом вызове; если пользователь теряет роль, право отсутствует начиная со следующего вызова (403 insufficient-scope). На странице согласия для не-администраторов оно заблокировано. API-ключей это не касается: их создаёт только ORG_ADMIN. Описание эндпоинтов не изменилось.

v1.90.0 · 12 октября 2026 г.

  • Чтение приёмов (право appointments:read): GET /appointments (список по началу, фильтры по периоду, статусу, типу приёма, ресурсу и контакту), GET /appointments/{id} (та же форма, что в вебхуках appointments.appointment.*, плюс места, участники и ведущие), GET /appointment-types и GET /appointment-types/{id} (все настройки, включая вид: индивидуальный, групповой или занятие, и услуги), GET /appointment-resources и GET /appointment-resources/{id}, GET /appointment-types/{id}/slots (свободное время, как при назначении внутри команды, не более 62 дней за запрос). Приёмы с лабораторным направлением видны только с доступом к данным клиентов; иначе их нет в списке, а отдельный запрос отвечает 404. Запись и настройка появятся в следующих версиях.

v1.89.0 · 12 октября 2026 г.

  • Шаблоны через API (область templates): GET/POST /message-templates, GET/PATCH /message-templates/{id} для шаблонов e-mail и SMS (формальная и неформальная версия, применение contacts или partnerPortal, purpose transactional или marketing), а также GET/POST /letter-templates, GET/PATCH /letter-templates/{id} для шаблонов писем (с нумерацией для {{brief.nummer}}). Чтение с templates:read, запись с templates:write и только если лицо за доступом — ORG_ADMIN (иначе 403 forbidden, ключ без создателя — 403 no-acting-user). Удаления нет: active: false выводит из использования. Неизвестные плейсхолдеры в шаблонах контактов отклоняют сохранение с 422.

v1.88.0 · 12 октября 2026 г.

  • Видеокомнаты (/rooms, права rooms:read/rooms:write): GET /rooms и GET /rooms/{id} (со ссылкой ведущего и гостя, пока комната открыта), POST /rooms/instant (мгновенная встреча с контактом; ведущий — создатель ключа), POST /rooms/{id}/participant-links (личная ссылка для приглашённого контакта или участника приёма), POST /rooms/{id}/close (только мгновенные встречи; комнаты приёмов закрываются с отменой приёма, иначе 409 с appointment-room), GET /rooms/{id}/recordings (видеозаписи и разговоры с documentId), а также GET/PATCH /rooms/settings (переключатель «Сводка», менять может только ORG_ADMIN). Видимость как у документов конференций (1.85.0): ORG_ADMIN видит все комнаты, остальные — только те, где они ведущие; ключ без создателя не видит ни одной. Новая причина room-not-configured в 422 precondition-failed; без права организации «Онлайн-комната» — 403 feature-not-available.

v1.87.0 · 12 октября 2026 г.

  • Три новые области с правами чтения и записи: rooms (видеокомнаты), templates (шаблоны писем, e-mail, SMS и PDF вместе с диапазонами номеров) и campaigns (e-mail-кампании). Эндпоинты появятся в следующих версиях; до тех пор права ещё не дают доступа. У шаблонов и кампаний свои права, потому что email:write разрешает только отправку, но не настройку и не массовую рассылку.
  • Два новых типа ошибок, оба 403: no-acting-user, если действие требует действующего лица (роль, отдельное право, автор), а у доступа его нет (API-ключ без создателя), и forbidden, если у лица доступа в организации нет права, которого требует интерфейс. Для ключа это тот, кто его создал, для OAuth-доступа — вошедший пользователь. Существующие эндпоинты свои ответы не меняют.

v1.86.0 · 12 октября 2026 г.

  • Новая область appointments (приёмы) с правами appointments:read и appointments:write. Эндпоинты появятся в следующих версиях; до тех пор право ещё не даёт доступа. Приёмы, к которым привязан лабораторный запрос, как и в вебхуках, считаются данными клиентов: они видны, только если организация разрешила данные клиентов для API и у доступа есть право clients:.

v1.85.0 · 12 октября 2026 г.

  • Документы: документы конференций (записи и сводки онлайн-комнаты) видят только ORG_ADMIN организации и ведущий разговора. Для API-ключа учитывается пользователь, создавший его; ключ без создателя не видит ни одного. Тогда они отсутствуют в GET /documents, а GET /documents/{id} отвечает 404. Описание эндпоинтов не изменилось, поэтому это указано здесь. События documents.* по-прежнему уходят на вебхуки организации, которые настраивает только ORG_ADMIN.

v1.84.0 · 11 октября 2026 г.

  • Новое событие letters.email.received: письмо поступило на адрес ответов SendGrid организации и получило оценку. email содержит id, conversationId, from, subject, receivedAt, sentiment (positive, neutral, negative, null, если оценка не удалась), contactId (или null) и campaignId, если письмо отвечает на кампанию (иначе null). Без текста письма. Отправляется только после оценки; письма через входящие Resend (документы, пересылки) его не вызывают. В автоматизациях это триггер «Получено письмо» с фильтрами по оценке и кампании.

v1.83.0 · 11 октября 2026 г.

  • Сценарии разговора (/call-guides): content.results задаёт результаты — именованные завершения с id, name и необязательным color (не более 20, название не более 80 символов), а result у шага (type: point) или ответа ссылается на один из них. Он действует только на завершении; в другом месте сохраняется и игнорируется, неизвестный идентификатор при чтении отбрасывается. Результат без названия при сохранении отклоняется с 422 и кодом ergebnis-ohne-name. До сих пор результаты, созданные в редакторе, терялись при обновлении через API.

v1.82.0 · 11 октября 2026 г.

  • callguides.run.completed теперь содержит guideRun.resultId и guideRun.resultName: именованный результат концовки, к которой пришёл проход (например, «Встреча назначена»). Организация задаёт результаты в сценарии и назначает их шагу без продолжения или ответу, ведущему к концу. Идентификатор и название берутся из версии, с которой шёл разговор. Если у этой концовки нет результата, оба значения null; outcome (последний шаг) не меняется.

v1.81.0 · 11 октября 2026 г.

  • leads.lead.created теперь наряду с consent (элемент → отмечен) содержит consentPurposes: цель каждого согласия, как в формах (1.79.0). INQUIRY — обязательная галочка «связаться по моему запросу», она не разрешает рекламу, MARKETING — добровольная галочка «реклама», null — собственная галочка или более старая, объединяющая запрос и рекламу. Тот, кто выводит из события согласие на рекламу, учитывает только MARKETING (или null) с consent = true. У лидов без формы (поиск специалистов, вручную) пустой объект.

v1.80.0 · 10 октября 2026 г.

  • kind у SMS (GET /sms, GET /sms/{id}, события sms.message.*) получил новое значение EINWILLIGUNG: нерекламная просьба подтвердить по ссылке согласие, данное в форме. Отправляется контакту через аккаунт Twilio организации, с названием организации в подписи.

v1.79.0 · 10 октября 2026 г.

  • Формы: каждое согласие теперь содержит purpose в определении формы (GET /forms/{id}) и в отправках (GET /forms/{id}/responses). INQUIRY — обязательная галочка «связь по моему запросу», MARKETING — добровольная галочка «реклама», null — собственная галочка или прежняя, объединяющая запрос и рекламу. У отправок до этой версии значение null. Согласием на рекламу является только MARKETING (или прежняя объединённая галочка); INQUIRY рекламу не разрешает.

v1.78.0 · 10 октября 2026 г.

  • Новое событие contacts.webhook.received: входящий хук организации принял и обработал запись из другой системы. hook содержит идентификатор и название, company — компанию (существующую или созданную, иначе null), contact — человека, а без человека саму компанию; contactStatus и companyStatus принимают значения new или existing. Входящие хуки создаются в настройках в разделе Интеграции → Интерфейсы: собственный адрес POST /api/hooks/‹id› (вне /api/v1, по выбору с обязательным Authorization: Bearer …), который сразу принимает JSON или формы до 256 КБ с ответом 202 и обрабатывает их в очереди для каждого хука (не более 60 в минуту; свыше 600 в минуту отвечает 429). В режиме обучения следующая доставка лишь сохраняется как образец, по которому сопоставляются поля.

v1.77.0 · 10 октября 2026 г.

  • Передача другим организациям: новая область handovers с правами handovers:read и handovers:write (у существующих ключей их нет). GET /handover-connections перечисляет активные соединения, через которые эта организация может передавать (id, name, recipientName). POST /handovers с connectionId и contactId (плюс contacts:read) копирует контакт вместе с компанией в получающую организацию и отвечает 201 с handoverId, никогда не сообщая, создан он или объединён. Ошибки: 404 (connection-unknown, not-your-connection, contact-unknown), 422 precondition-failed (connection-revoked, connection-not-active), 500 (copy-failed). У получателя передача вызывает contacts.handover.received (с 1.75.0); в автоматизациях для него есть фильтр по соединению и действие «Передать организации».

v1.76.0 · 10 октября 2026 г.

  • Цели вебхуков: именованные адреса других систем, на которые отправляется контакт вместе с компанией, например новым действием «Отправить вебхук» в автоматизациях. В отличие от /webhooks, цели не подписываются на события. Новое: GET /webhook-targets, GET /webhook-targets/{id}, GET /webhook-targets/{id}/deliveries (журнал, 30 дней, с началом ответа) и POST /webhook-targets/{id}/send с contactId (202, права webhooks:manage и contacts:read; 409 conflict с reason: target-inactive, если цель выключена). Отправка идёт в конверте событий с type: contacts.contact.sent и data = { contact, company, automation, test }, с подписью по Standard Webhooks секретом цели, с повторами через 1 мин, 5 мин, 30 мин, 2 ч и 12 ч; после пяти неудачных отправок подряд цель отключается. Создание, изменение, секрет и проверка — в настройках в разделе Интеграции → Интерфейсы.

v1.75.0 · 10 октября 2026 г.

  • Новое событие contacts.handover.received: другая организация передала этой контакт через соединение передачи. contact — контакт в этой организации (созданный заново или объединённый с существующим), company — его компания или null, handover указывает передачу, соединение (connectionId, connectionName) и outcome (created или merged). На него можно подписаться, как на любое событие, и оно служит триггером в автоматизациях. Сами соединения передачи появятся в одной из следующих версий.

v1.74.0 · 9 октября 2026 г.

  • Переписка: POST /outbound-emails и POST /sms по выбору принимают vorlageId, идентификатор шаблона из общего набора (применение «Контакты»). Тогда тема, текст, версия на «ты» (Du) и вид отправки берутся из шаблона в момент отправки, с его заполнителями (например {{person.firstName}}, {{anrede}}); кто меняет шаблон, меняет следующую отправку. Либо vorlageId, либо свободный текст: для письма subject и bodyHtml теперь обязательны только без vorlageId, для SMS body и art; вместе с vorlageId их передавать нельзя, а для SMS тогда обязателен contactId. Письмо из шаблона отправляется как из переписки с контактом (kind: gespraech, подпись с кодом переписки; рекламные шаблоны только при согласии на e-mail и со ссылкой для отписки). Новые причины в 422 precondition-failed: message-template-not-found, message-template-archived (устранимо), message-template-without-sms (устранимо, только SMS), email-ohne-einwilligung.

v1.73.0 · 8 октября 2026 г.

  • Формы: согласие на e-mail или телефон теперь считается запрошенным, только если заполнено поле его канала. Если поле пустое, согласие больше не попадает в consents отправки (GET /forms/{id}/responses, forms.response.submitted) и в consent события leads.lead.created, даже как отклонённое; переданное true в POST /forms/{id}/responses в этом случае не сохраняется. Раньше оно указывалось всегда, с accepted: false или даже true для несуществующего адреса. Свободные согласия (канал CUSTOM) не изменились.

v1.72.0 · 8 октября 2026 г.

  • Контакты: новое поле dateOfBirth («YYYY-MM-DD», только PERSON, от 1900 года до сегодняшнего дня) во всех ответах и событиях контактов, задаётся через POST /contacts и PATCH /contacts/{id} (null очищает). Тот же формат, что clients.dateOfBirth, но у контакта; недопустимая дата или дата у компании возвращает 422 validation-failed (body.dateOfBirth).

v1.71.0 · 8 октября 2026 г.

  • Новые события для приёмов: appointments.appointment.booked (подтверждён; при обязательной оплате — после оплаты), appointments.appointment.rescheduled (с previousStartsAt, previousEndsAt и by: customer или provider), appointments.appointment.cancelled (с by и reason) и appointments.appointment.noShow (отмечено командой, с markedByUserId). Полезная нагрузка содержит приём в appointment, контакт — в appointment.contactId; автоматизации могут использовать эти события как триггеры. Сообщается только о подтверждённых приёмах. Приём с лабораторным направлением отправляется только на конечные точки с доступом к данным клиентов.

v1.70.0 · 8 октября 2026 г.

  • Новое событие calls.call.ended: звонок завершён, ровно один раз на звонок. call содержит направление (inbound, outbound), результат (answered, missed, voicemail для нашего автоответчика, failed), контакт (contactId, null для неизвестного номера), собеседника, номера, время и durationSeconds. Заметки, запись и расшифровка разговора никогда не передаются.
  • Новое событие callguides.run.completed: сценарий разговора завершён во время звонка (основной путь дошёл до конца, обязательных шагов не осталось), ровно один раз на прохождение; последующие изменения не вызывают его повторно. guideRun содержит сценарий (guideId), контакт (contactId: собеседник, иначе контакт звонка), outcome (ID последнего шага), answers (вопрос → ответ в виде ID), использованные возражения и путь. Заметки никогда не передаются.

v1.69.0 · 8 октября 2026 г.

  • Контакты, новые эндпоинты для отдельных изменений (действия автоматизаций): POST /contacts/{id}/tags (tagId из набора или tag текстом) и DELETE /contacts/{id}/tags/{tag} (ID или текст) добавляют или удаляют один тег без отправки всего списка; существующий или отсутствующий тег ничего не меняет и не вызывает второго события. POST /contacts/{id}/notes создаёт заметку (простой текст, сохраняется как экранированный HTML). PUT /contacts/{id}/custom-fields/{slug} задаёт своё поле (value: текст, список ключей вариантов или null; не поля только карты клиента и не согласия). PUT /contacts/{id}/owner назначает ответственного (userId участника или null). Обращение Du/Sie и стандартные поля по-прежнему через PATCH /contacts/{id}.

v1.68.0 · 8 октября 2026 г.

  • Новое событие funnels.funnelLead.created: лид из формы воронки или сайта — с отправкой (lead.id), площадкой (lead.funnelId, lead.funnelName, lead.funnelKind), страницей формы (lead.stepId, lead.stepName, lead.stepPath), формой и контактом (lead.contactId). Только идентификаторы и названия, без персональных данных. Отправляется дополнительно к leads.lead.created и доступно в автоматизациях как триггер «Лид из воронки или с сайта».
  • leads.lead.created из воронки теперь содержит contactId и тогда, когда отправка создала потенциального клиента (его контакт); раньше там было null.

v1.67.0 · 8 октября 2026 г.

  • Договоры из шаблона (POST /contracts): новое поле send (по умолчанию false, как раньше только черновик). При true договор отправляется, как только его PDF сформирован; ответ ещё показывает черновик, об отправке сообщает событие esign.request.sent. Дополнительно reminderPolicy и locale, как в POST /signature-requests/{id}/send. Если формирование не удалось или длится дольше десяти минут, черновик остаётся.

v1.66.0 · 8 октября 2026 г.

  • Ответы на формы (GET /forms/{id}/responses, GET /forms/responses/{id}, событие forms.response.submitted): новое поле contactId — контакт, к которому относится ответ; null, пока его нет, и всегда для анкет карты клиента. Теперь в автоматизациях с триггером «Форма отправлена» доступны действия с контактом.
  • Ответы на формы: новое значение booking для source — отправлено через запись на встречу. Раньше такие ответы отображались как api.

v1.65.0 · 5 октября 2026 г.

  • Сценарии разговора: новый тип действия consent ({ type: "consent", channel: "EMAIL" }) — зафиксировать по телефону согласие на e-mail; формулировка берётся из контактов во время выполнения. channel пока только EMAIL; любое другое значение возвращает 422 validation-failed.

v1.64.0 · 5 октября 2026 г.

  • Сценарии разговора (/call-guides) с действиями и вводом, всё необязательно: пункт может быть action (email, sms, callback, handover, checkout, appointment, form) или через field записывать ввод в поле собеседника; вопрос через field записывает выбранный ответ, а при заданном value у ответа — это значение (например, ключ варианта выбора); mandatory: true делает шаг обязательным; actions размещает действия сбоку разговора. Новые причины проверки для body.content: aktion-unvollstaendig (нет шаблона или ссылки, действие сбоку без названия) и action-and-field (пункт с тем и другим). При чтении и обратной записи сценария эти части сохраняются.

v1.63.1 · 5 октября 2026 г.

  • Уточнение к 1.63.0 (ещё не выпущена): contactFields в сценариях разговора принимает только ключи, которые может показать мини-окно сбоку разговора: title, website, addressStreet, addressPostalCode, addressCity или cf:<slug> (строчные буквы, цифры, _). Другой ключ возвращает 422 validation-failed, а не отбрасывается молча.

v1.63.0 · 5 октября 2026 г.

  • Сценарии разговора (/call-guides) умеют больше, всё необязательно: для шага hint (подсказка только для человека у телефона) и cards (карточки-подсказки с title, text, color); для сценария cards (видны всегда), objections (возражения с name и start, первым шагом их собственного пути) и contactFields (дополнительные поля для мини-окна сбоку разговора). Заполнители работают и в подсказках, и в карточках. Новые причины проверки для body.content: karte-leer и einwand-unvollstaendig.

v1.62.0 · 5 октября 2026 г.

  • Новое: сценарии разговора для телефонии (чек-листы с ветвлением для звонков). GET /call-guides, GET /call-guides/{id}, POST /call-guides и PATCH /call-guides/{id}, новые права callguides:read и callguides:write; в API-MCP как инструменты callguides_list, callguides_get, callguides_create и callguides_update. У сценария есть start и nodes: point для отметки или question с answers; next ведёт дальше (нет: следующий узел списка, null: конец, ID: к этому узлу). Сохраняется только содержимое без ошибок, иначе 422 с причинами для body.content. Каждое изменение названия, описания или содержимого — новая версия (version); active переключает без новой версии.

v1.61.0 · 4 октября 2026 г.

  • Обязательное поле art в POST /sms (также MCP letters_sendSms и действие LeadConnector sms-send): notwendig (необходимое) или werblich (рекламное), без значения по умолчанию; запрос без art возвращает 422 validation-failed для body.art. Это строже прежнего, но никого не затрагивает: в production не было ни одного вызова POST /sms. Тип отправки определяет подпись SMS (необходимое: название организации; рекламное: название и «Keine SMS mehr? STOP antworten»), которая добавляется к body и учитывается в числе сегментов, а рекламное SMS уходит только контакту (contactId) с согласием на SMS: без контакта 422 precondition-failed с reason = sms-werblich-ohne-kontakt, без согласия для номера reason = sms-ohne-einwilligung (оба fixable: false).

v1.60.2 · 4 октября 2026 г.

  • Исправлено: POST /documents с contactId связывает документ с этим контактом, и связь теперь сохраняется после анализа документа. Раньше автоматическое сопоставление могло перезаписать её результатом поиска по имени или пустым значением, и GET /documents/{id} показывал другой контакт или никакой. Теперь автоматическое сопоставление заполняет только пустое; то же относится к PATCH /documents/{id} с contactId и последующему повторному анализу.

v1.60.1 · 4 октября 2026 г.

  • Уточнение к 1.60.0, которая ещё не была выпущена: SMS участнику (channel: sms) отправляется на стандартный номер из его профиля, если в этой организации он не указал номер для SMS-подтверждения, как при подписании и напоминаниях о записях. member-without-phone возникает, только если нет ни того, ни другого.

v1.60.0 · 4 октября 2026 г.

  • POST /organization/members/{userId}/notifications теперь может отправить и SMS: channel: sms уходит на мобильный номер, который участник указал для SMS-подтверждения в этой организации, иначе на стандартный номер из профиля (тот же порядок, что при подписании и напоминаниях о записях), через аккаунт Twilio организации; текст — title и body. Если нет ни того, ни другого: 422 precondition-failed, reason = member-without-phone, fixable: true; если он недействителен: member-phone-invalid. Причины отправки SMS (twilio-*) действуют как для POST /sms (1.58.0), сетевые ошибки 500. SMS появляется в GET /sms с kind: API.

v1.59.0 · 4 октября 2026 г.

  • kind у SMS (GET /sms, GET /sms/{id}, события sms.message.*) получил новое значение GESPRAECH: SMS, которое сотрудник написал вручную в переписке с контактом. Если вы обрабатываете kind, допускайте неизвестные значения.

v1.58.0 · 4 октября 2026 г.

  • POST /sms теперь отправляет только через собственный аккаунт Twilio организации (Организация → Интеграции); это касается и автоматизаций, и действия LeadConnector sms-send. Без подключённого аккаунта, без номера отправителя или с недействительным доступом запрос возвращает 422 precondition-failed с reason = twilio-nicht-verbunden, twilio-keine-nummer или twilio-zugang-ungueltig и fixable: true; SMS при этом не создаётся (раньше строка со статусом FAILED и 403 feature-not-available). Если получатель отправил STOP: 422 precondition-failed, reason = twilio-empfaenger-gesperrt, fixable: false (часто только в обратном вызове, тогда FAILED с errorCode у SMS). Номер недействителен по данным Twilio: 422 validation-failed для body.to. Иной отказ: 409 conflict, reason = twilio-abgelehnt. Сетевая ошибка: 500, можно повторить.
  • Лимит в 300 SMS на организацию в месяц отменён, так как с этой версии каждая организация сама оплачивает свои SMS. 429 sms-limit-reached больше не возникает; код остаётся в каталоге до v2.

v1.57.0 · 4 октября 2026 г.

  • POST /organization/members/{userId}/notifications теперь может отправлять и e-mail: channel: email уходит на адрес участника, title становится темой, body текстом, link адресом в приложении. Если отправка не удалась, запрос возвращает 500 и его можно повторить. Ответ содержит использованный канал.
  • К документам карты клиента теперь относятся и вложения почты карты (сообщения портала в разделе карты). Для них действуют те же правила, что для лабораторных бланков и договоров с клиентами (1.54.0): без разрешения данных клиентов и права clients: их нет в GET /documents, запрос по идентификатору (включая …/download-url и PATCH) возвращает 404, а события documents.document.* о них доставляются только на endpoints с clientsData: true.

v1.56.0 · 4 октября 2026 г.

  • Новое: POST /organization/members/{userId}/notifications отправляет участнику организации сообщение в колокольчик (с push-уведомлением в браузере, если оно включено): title, необязательно body и link (путь в приложении). Новое право members:notify; в остальном участники остаются только для чтения. Пользователь, не являющийся участником, возвращает 404. Канал пока только channel: notification; e-mail и SMS будут добавлены как новые значения.

v1.55.0 · 4 октября 2026 г.

  • POST /outbound-emails принимает версию на «ты» (Du): subjectDu и bodyHtmlDu, обе необязательны и действуют только вместе. Тогда claritos выбирает для каждого получателя по правилу обращения (обязательное «вы» для писем, личное «ты» при OAuth, настройка у контакта, иначе стандарт организации), и заполнители вроде {{ansprechpartner.anrede}} следуют тому же выбору. Если одной из них нет, письмо уходит полностью в версии на «вы», как и раньше. Выбор для каждого получателя подготовлен и будет включён для всех организаций одновременно; до тех пор каждое письмо уходит в версии на «вы», но версию на «ты» уже можно передавать.
  • Описание теперь перечисляет все ответы с ошибкой, которые может вернуть каркас: 409 для изменяющих запросов (конфликт, ещё выполняющийся запрос с тем же Idempotency-Key), 413 для запросов с телом (больше 1 МБ) и 500 везде. Поведение не изменилось; раньше эти коды лишь отсутствовали в описании.

v1.54.0 · 3 октября 2026 г.

  • Вебхуки с данными клиентов теперь доставляются только на разрешённые endpoints. Новое поле clientsData в GET/POST/PATCH /webhooks: только endpoint с clientsData: true получает события с данными клиентов, то есть clients.record.created, clients.record.updated, clients.message.received и события esign.request.* по договору с клиентом, и только пока организация разрешила данные клиентов для API. Установить clientsData: true можно только с clients:read или clients:write (иначе 403 insufficient-scope) и только при разрешении (иначе 403 clients-data-not-enabled). Проверка выполняется при каждой попытке доставки; если разрешение отозвано, ожидающая доставка завершается со статусом FAILED и lastError = clients-data-not-allowed. Повторная отправка пропускает такие события для неразрешённого endpoint, а GET /webhooks/events/{type}/recent показывает их только ключу с правом clients:. До сих пор события clients.* доставлялись на любой endpoint организации.
  • Документы карты клиента (лабораторные бланки, договоры с клиентами) /documents возвращает только пока организация разрешила данные клиентов для API и ключ имеет право clients:; иначе их нет в GET /documents, а запрос по идентификатору (включая …/download-url и PATCH) возвращает 404. Для договора действует то же исключение, что и в 1.53.0: его создал или отправил пользователь, стоящий за ключом.
  • События documents.document.ready, documents.document.analyzed и documents.document.updated по документам карты клиента (лабораторные бланки, документы договора с клиентом) считаются данными клиентов: они доставляются только на endpoints с clientsData: true и только при разрешении данных клиентов в организации. В отличие от запросов, здесь нет исключения для создателя или отправителя, потому что вебхук не принадлежит пользователю.

v1.53.0 · 3 октября 2026 г.

  • Договоры с клиентами только при разрешении клиентских данных: если в договоре или запросе на подпись участвует контакт с картой клиента (или его представитель), GET /contracts, GET /signature-requests, одиночные запросы, …/events, …/pdf, …/send и …/cancel возвращают его, только если организация разрешила клиентские данные для API и у ключа есть право clients:; иначе его нет в списках, а запрос по идентификатору отвечает 404. Исключение: договоры, которые создал или отправил пользователь, стоящий за ключом. Списки остаются полными, hasMore верен.

v1.52.0 · 3 октября 2026 г.

  • Поля карты клиента в шаблонах договоров: если организация ведёт практику, шаблоны также знают поля карты клиента как <сторона>.akte.<поле> (дата рождения dateOfBirth, номер карты recordNumber, начало сопровождения careStartedAt и конец careEndedAt, собственные поля карты и поля «только практика» как <сторона>.akte.custom.<slug>). variables перечисляет их. POST /contracts заполняет их, только если организация разрешила клиентские данные для API и у ключа есть право clients:; иначе там стоит •••, и карта не читается.

v1.51.0 · 3 октября 2026 г.

  • Шаблоны договоров знают больше переменных: для каждой компании, контактного лица и человека доступны все поля контакта (например, company.1.email, company.1.legalFormName, company.1.contact.1.firstName, person.1.customerNumber), а также собственные поля организации как <сторона>.custom.<slug> (например, company.1.contact.1.custom.jahrgang). variables в GET /contract-templates перечисляет их, и warnings больше не сообщает о них как unknown-variable. POST /contracts заполняет их из контактов. Также новое countryName (название страны на языке шаблона) рядом с country (код страны, например DE, без изменений). Все существующие переменные сохраняются.

v1.50.1 · 2 октября 2026 г.

  • POST /contract-templates/{id}/archive отвечает 200 вместо 201: архивирование ничего не создаёт. Так же отвечают и остальные действия, которые ничего не создают, например у предложений и документов.

v1.50.0 · 2 октября 2026 г.

  • Шаблоны договоров теперь можно создавать, изменять и архивировать: POST /contract-templates, PATCH /contract-templates/{id} и POST /contract-templates/{id}/archive, право contracts:write, с теми же полями и проверками, что и в редакторе шаблонов. bodyHtml очищается при сохранении: остаётся разметка редактора; скрипты, атрибуты событий, ссылки кроме http, https, mailto и tel, а также изображения вне собственного хранилища организации удаляются. Ответ содержит warnings с удалённым и с плейсхолдерами, которых не знают ни план сторон, ни фиксированные переменные (unknown-variable). Недействительный план сторон возвращает 422, изменение архивированного шаблона 409 (archived), не деловая организация feature-not-available. Новое при чтении любого шаблона: anrede (AUTO, SIE, DU) и isFeeAgreement; formal остаётся.

v1.49.0 · 2 октября 2026 г.

  • Контакт типа PERSON с номером НДС отклоняется (422 validation-failed, путь body.vatId, код invalid_combination): у кого есть номер НДС, тот является компанией. Это касается POST /contacts и PATCH /contacts/{id}, если изменение присваивает человеку номер НДС. Вместо этого создайте компанию (type: COMPANY, правовая форма индивидуального предпринимателя) с номером НДС и привяжите к ней человека как контактное лицо через worksAtId. Изменения существующих контактов, которые ещё сохранены как человек с номером НДС, остаются возможными, пока они не задают номер НДС.

v1.48.0 · 1 октября 2026 г.

  • У напоминаний об оплате (GET /dunning/reminders, GET /dunning/reminders/{id}) появился новый статус SUPERSEDED: напоминание заменено более поздним по тому же требованию и больше не принимает оплату. Это происходит, как только фиксируется следующая ступень; до сих пор предыдущее оставалось в статусе SENT. Кроме того, напоминания, отправленные вне claritos до начала работы с ним, теперь можно задним числом внести как звено цепочки. Они отображаются со status: SENT, number: null и feeCents/interestCents, равными 0. portalUrl заменённого или внесённого напоминания ведёт к действующему напоминанию или к счёту. Если вы обрабатываете статус, рассматривайте SUPERSEDED как завершённую ступень, а не как открытое требование оплаты.

v1.47.0 · 27 сентября 2026 г.

  • У документов появилось новое поле access со значением public или protected (GET /documents, GET /documents/{id}, PATCH /documents/{id}, а также вебхуки documents.document.ready, .analyzed и .updated). Защищённые документы не доступны публично: у них url и previewUrl всегда равны null, даже когда документ готов. Файл получают по подписанной ссылке из GET /documents/{id}/download-url. Сейчас это касается только новых записей Zoom. Начиная с этой версии url помечено как устаревшее: позже оно станет null для всех документов, и GET /documents/{id}/download-url будет единственным способом получить файл. Если вы сохраняете url, переходите на download-url уже сейчас.

v1.46.0 · 26 сентября 2026 г.

  • Поле addressForm у форм (GET /forms, GET /forms/{id}) теперь может возвращать и AUTO, наряду с DU (на «ты») и SIE (на «вы»). AUTO означает, что у формы нет фиксированного обращения: она обращается так, как это задано организацией или контактом. Какое обращение фактически увидит человек, claritos решает при показе формы. Новые формы по умолчанию стоят на AUTO, а существующие формы с DU переведены на AUTO, кроме шаблонов анамнеза, в которых сами вопросы сформулированы на «ты». Если вы до сих пор считали всё, кроме SIE, обращением на «ты», не относите AUTO к «ты».

v1.45.0 · 26 сентября 2026 г.

  • Изменено поведение POST /signature-requests с send: true и POST /signature-requests/{id}/send: приглашения теперь отправляются всегда. Если подключение Gmail отправителя истекло, они уходят с адреса claritos, а ответы по-прежнему получает отправитель. До сих пор в этом случае они не отправлялись, а senderInvalid было true. Поэтому с версии 1.45.0 senderInvalid всегда false, помечено как устаревшее и будет удалено в v2. Если вы реагировали на него, например предложением «переподключить почтовый ящик», этот сигнал больше не приходит; подключение помечается в claritos как недействительное, и его владельцу там предлагается подключить его заново.

v1.44.0 · 26 сентября 2026 г.

  • У контактов появилось поле anrede: STANDARD (как настроено в организации), DU (на «ты») или SIE (на «вы»). Доступно для чтения во всех методах контактов и в вебхуках contacts.contact.created и contacts.contact.updated, для записи при создании и изменении. Действует только для людей: для компаний важно контактное лицо, там всегда возвращается STANDARD, а DU или SIE у компании отклоняется с кодом 422 (validation-failed, путь body.anrede).

v1.43.0 · 25 сентября 2026 г.

  • Новое поле paymentProvider у счетов, предложений и заказов, а также у их разделов: MOLLIE, если оплата онлайн идёт через платёжный слой, иначе null. Доступно для чтения везде, для записи у счетов и предложений (заголовок и разделы). Исключает stripeEnabled (один онлайн-провайдер); чтобы перейти со Stripe на Mollie, в том же вызове укажите stripeEnabled: false. Установить можно, только если организация подключила Mollie, иначе validation-failed. При записи разделов отсутствие поля означает «без провайдера». События invoices.invoice.* тоже содержат это поле.

v1.42.0 · 25 сентября 2026 г.

  • Новое событие letters.certificate.expired для документов из PDF-шаблонов со сроком действия (например, сертификат, действующий три года). Оно отправляется один раз, на следующий день после последнего дня действия; если ежедневный запуск был пропущен, оно досылается в течение трёх дней. Событие содержит certificate (идентификатор, шаблон, номер, контакт, validUntil, signed, код проверки) и contact. Отозванные документы и документы, ожидающие подписи, ничего не отправляют. Напоминание до истечения срока является не событием, а триггером автоматизаций по дате.

v1.41.0 · 24 сентября 2026 г.

  • POST /letters/{id}/send теперь отказывает в отправке с 409 conflict и reason = certificate-attachment-invalid, если вложение является выданным документом (сертификатом из PDF-шаблона) в недействительной версии: аннулированным, ещё не подписанным или заменённым подписанной версией. До сих пор такое вложение отправлялось. Та же проверка действует для писем из действия «Письмо из шаблона».

v1.40.0 · 24 сентября 2026 г.

  • Новые эндпоинты для автоматизаций и интеграций. POST /letters/from-template создаёт письмо из шаблона письма для контакта и отправляет его, как только готов PDF (channel: EMAIL, POSTAL или BOTH; ответ 202 с письмом в статусе DRAFT). POST /outbound-emails отправляет произвольное письмо контакту; тема и текст могут содержать те же плейсхолдеры, что и шаблоны писем, а запись затем появляется в GET /outbound-emails с kind = message. Если у контакта нет нужных данных, оба эндпоинта отвечают precondition-failed с reason, например contact-without-email, contact-without-address, postal-not-connected, template-archived или sender-invalid. Перехода на другой канал доставки нет.
  • При вызове из автоматизации оба эндпоинта распознают продолжение того же запуска: тот же шаг находит то же письмо или тот же e-mail, а не создаёт второй. Если письмо не удалось доставить уже после принятия (202), действующий пользователь получает уведомление; вызывающая сторона об этом пока не уведомляется.

v1.39.0 · 24 сентября 2026 г.

  • Новый код ошибки precondition-failed (422): не выполнено предварительное условие объекта, например у контакта нет адреса электронной почты. Ответ содержит reason (стабильный код, например contact-without-email) и fixable (можно ли устранить ошибку, изменив данные). Для повтора после исправления данных нужен новый Idempotency-Key: хранилище запоминает и этот ответ с ошибкой.

v1.38.0 · 24 сентября 2026 г.

  • Новые события contacts.tag.added и contacts.tag.removed: по одному событию на каждый тег, который назначен контакту или снят с него, с contactId и tag в той же форме, что и tagDetails (идентификатор, текст, описание, источник, группа). Событие отправляется только после сохранения изменения. Другое написание того же тега изменением не считается. Переименование, объединение и удаление в управлении тегами не вызывают событий, как и объединение контактов.

v1.37.0 · 24 сентября 2026 г.

  • kind у SMS (GET /sms, GET /sms/{id}, события sms.message.*) получил новое значение APPOINTMENT_REMINDER для напоминаний о встречах. До сих пор напоминания имели API, хотя отправлялись не через API; более ранние напоминания сохраняют API. Напоминания о встречах не учитываются в лимите SMS (sms-limit-reached).
  • Добавлено задним числом: два значения вошли в контракт без собственной записи. (1) С 13.09 тип поля формы (GET /forms/{id}) может быть UPLOAD; ответом на такое поле служит идентификатор документа. (2) С 24.09 taxCategory у артикулов и у позиций предложений, заказов и счетов может иметь значение OUTSIDE_SCOPE (не облагается налогом внутри страны, § 3a закона об НДС Германии). Клиентам, которые обрабатывают эти поля полностью, следует знать оба значения.

v1.36.0 · 24 сентября 2026 г.

  • Запросы на подпись теперь знают источник PDF_TEMPLATE: документ, созданный по PDF-шаблону, например сертификат с порядковым номером. Значение появляется в поле sourceKind запросов в /esign, как фильтр ?sourceKind=PDF_TEMPLATE и в данных событий esign.request.*. Если вы обрабатываете sourceKind полностью, например в switch, добавьте новое значение.

v1.35.0 · 24 сентября 2026 г.

  • Новый код ошибки sms-limit-reached (429) для POST /sms: через API, действие LeadConnector и автоматизации организация отправляет не более 300 SMS за календарный месяц (по немецкому времени); значение настраивается для каждой организации. Ответ содержит limit, used и resetsAt и заголовок Retry-After до начала следующего месяца. Напоминания о встречах не учитываются.

v1.34.0 · 24 сентября 2026 г.

  • Изменено поведение tags у документов: PATCH /documents/{id} больше не сохраняет теги в нижнем регистре и с - вместо пробелов. Каждый тег возвращается в написании из справочника тегов организации; если отправить VIP, когда vip уже существует, вернётся vip. Теги, отличающиеся только регистром, пробелами или дефисами, считаются одним тегом. Неизвестный тег создаётся в том виде, в каком он отправлен; пробелы и специальные символы сохраняются, раньше пробелы заменялись на -, а специальные символы удалялись.
  • Фильтр GET /documents?tag= теперь находит теги независимо от регистра, пробелов и дефисов; раньше он сравнивал точно.

v1.33.0 · 24 сентября 2026 г.

  • У контактов рядом с tags теперь есть tagDetails: для каждого тега постоянный идентификатор (id), текст (tag), пояснительное описание (label), источник (source) и группа (group или null). Ту же форму получат планируемые события добавления и снятия тега. Вебхуки contacts.contact.created и contacts.contact.updated тоже передают это поле. Идентификатор не меняется при переименовании тега; для сопоставления тегов используйте его, а не текст.
  • Изменено поведение tags: теги контактов больше не приводятся к нижнему регистру. Они возвращаются в написании из справочника тегов организации; если отправить VIP, когда vip уже существует, вернётся vip. Теги, отличающиеся только регистром, считаются одним тегом. Пробелы и специальные символы сохраняются; раньше пробелы заменялись на -, а специальные символы удалялись. Фильтр ?tag= теперь находит теги независимо от регистра; раньше теги с заглавными буквами не находились.

v1.32.1 · 15 сентября 2026 г.

  • Открытые позиции (/open-items) теперь доступны для любого типа организации, включая личные сферы и домохозяйства. Ранее API отвечал там feature-not-available, хотя приложение ведёт эти позиции. Без изменений: напоминания (/dunning/reminders) остаются только для бизнес-организаций.

v1.32.0 · 7 сентября 2026 г.

  • Основа OAuth переведена на Better Auth 1.7 (новый плагин oauth-provider). Новое: отзыв и проверка токенов как отдельные точки, токены, привязанные к ресурсу, публичные клиенты без секрета, более строгая аутентификация клиентов. Закрыты две уязвимости прежней версии. Существующие подключения OAuth нужно один раз создать заново — клиенты, согласия и токены старой версии не переносятся. API-ключи (capi_) не затронуты.

v1.31.0 · 7 сентября 2026 г.

  • MCP конструктора сайтов: список инструментов теперь фильтруется по разрешениям — доступ с sites:read больше не видит инструменты записи. Прямой вызов запрещённого инструмента по-прежнему отвечает 403 insufficient_scope.

v1.30.0 · 7 сентября 2026 г.

  • Подключённые приложения в профиле: пользователи видят каждое разрешение OAuth (приложение, организация, разрешения обычными словами, действующие доступы, последний вход) и могут отозвать его сами. Отзыв удаляет привязку к организации, выданные токены и согласие — приложение сразу теряет доступ и при следующем подключении спрашивает заново.

v1.29.0 · 7 сентября 2026 г.

  • Пункт меню LeadConnector: claritos может отображаться как custom menu link в LeadConnector (/embed/leadconnector в iframe). Зашифрованный контекст локации от LeadConnector читается ключом SSO приложения и показывает связанную организацию, активные триггеры и доступные действия. Контекст подтверждает локацию, а не личность в claritos — он не создаёт вход, и страница не показывает бизнес-данные.

v1.28.0 · 7 сентября 2026 г.

  • Приложение Zapier: вход теперь через OAuth 2.1 (authorization code + PKCE, автоматическое обновление токена) вместо API-ключа — условие для публичного размещения. При подключении пользователи выбирают организацию и разрешения в согласии claritos; список запрашиваемых scopes генерируется из спецификации и не включает клиентские данные. Недостающие разрешения приходят как 403 в соответствующем действии.

v1.27.0 · 7 сентября 2026 г.

  • События оформления заказа в стандартном формате: payments.checkout.pending / .completed / .failed (продажи по платёжной ссылке) теперь идут и через сервис вебхуков API — со стандартной подписью, повторами, журналом доставки, повтором отправки и оповещениями. Существующие вебхуки платёжной ссылки не меняются; для перехода подпишитесь на новые типы и отключите старую цель.

v1.26.0 · 7 сентября 2026 г.

  • Согласие OAuth: разрешения можно снимать по отдельности (least privilege). Клиент получает только выбранные scopes — даже если запросил все; scopes клиентских данных по умолчанию сняты. Согласие без выбранного разрешения больше невозможно; пустой grant означает «нет прав API».

v1.25.0 · 6 сентября 2026 г.

  • MCP конструктора сайтов (POST /api/mcp) теперь принимает и OAuth 2.1 access-токены (вход + согласие, scopes sites:read/sites:write) — чат-коннекторам (claude.ai, ChatGPT) больше не нужен cmcp_-токен; cmcp_-токены остаются действительными. Scopes проверяются для каждого инструмента (get_/list_/verify_/suggest_ = чтение, остальное = запись; 403 insufficient_scope). Метаданные защищённого ресурса для каждого MCP-сервера: /.well-known/oauth-protected-resource/api/mcp и …/api/mcp/v1.

v1.24.0 · 6 сентября 2026 г.

  • Пользовательское приложение Make (integrations/make): дерево приложения полностью сгенерировано из спецификации — подключение API-ключ + среда, вебхук (attach/detach через /webhooks), один instant-триггер на тип события, модули action/search/get/delete на каждую конечную точку (поиск с курсорной пагинацией, действия с Idempotency-Key), отображение ошибок Problem Details; скрипт загрузки для Make Apps SDK API. Руководство «Make». Теперь все четыре платформенных приложения (LeadConnector, Zapier, n8n, Make) находятся в репозитории.

v1.23.0 · 6 сентября 2026 г.

  • Community-узел n8n (integrations/n8n, npm n8n-nodes-claritos): обычный узел с resource = домен и operation = конечная точка (декларативно, сгенерировано из спецификации; списки распаковываются в data), триггер-узел с подпиской через POST /webhooks, проверкой подписи и очисткой при деактивации, учётные данные API-ключ + среда. Руководство «n8n».

v1.22.0 · 6 сентября 2026 г.

  • Приложение Zapier (integrations/zapier): один REST-hook-триггер на тип события (подписка через POST /webhooks, проверка подписи, «Load sample» из /webhooks/events/{type}/recent), действия для всех конечных точек записи, поиск по всем спискам — полностью сгенерировано из спецификации. Новый снимок docs/api/events.v1.json (каталог событий с примерами). Руководство «Zapier».

v1.21.0 · 6 сентября 2026 г.

  • Приложение LeadConnector Marketplace (путь C): установка на локацию (OAuth из настроек организации или External Authentication с API-ключом), пользовательские действия workflow (contact-create, task-create, sms-send, quote-create, invoice-create, form-response — через API-фреймворк с ключом пользователя), пользовательские триггеры workflow (lead_created, contact_created, invoice_paid, invoice_issued, quote_accepted, esign_completed, form_submitted, task_done — внутри это webhook-адреса). Руководство «LeadConnector».

v1.20.0 · 6 сентября 2026 г.

  • MCP поверх API: POST /api/mcp/v1 (Streamable HTTP) — один инструмент на конечную точку (имя <domain>_<action>, ввод params/query/body как в справочнике, необязательный idempotencyKey при записи). Та же аутентификация (API-ключ или OAuth 2.1), те же scopes, гейт клиентских данных, лимиты и протокол, что и по HTTP; список инструментов показывает только разрешённое. Руководство «MCP».

v1.19.0 · 6 сентября 2026 г.

  • OAuth 2.1: помимо API-ключей API теперь принимает OAuth-токены доступа (код авторизации + PKCE, refresh-токены, динамическая регистрация клиентов). Пользователь в окне согласия открывает ровно одну организацию; scopes те же, что у ключей. Discovery по адресам /.well-known/oauth-authorization-server и /.well-known/oauth-protected-resource. Руководство «OAuth» (потоки, согласие, Zapier/n8n).

v1.18.0 · 6 сентября 2026 г.

  • Каталог специалистов + продукты (только чтение): GET /finder/practitioners (фильтры по радиусу, месту, языку, квалификации и теме; тот же поиск, что и на публичной странице каталога организации), GET /finder/practitioners/{slug} (профиль с адресами, направлениями, квалификациями; старые slug разрешаются), GET /finder/places (подсказки мест). GET /foods/search (результаты по категориям), GET /foods (список по категории), GET /foods/{id} (по ID или slug) — глобально, питательные вещества на 100 г, данные о порции, источник и указание источника в каждом ответе.

v1.17.0 · 6 сентября 2026 г.

  • Организация (только чтение): GET /organization (реквизиты, адрес, налоговые/регистрационные данные, банк, логотип, адрес входящих, брендовый домен, уровень электронной подписи, настройки API), GET /organization/members (участники с ролью, видимостью, доступом к клиентам), GET /organization/invitations (приглашения; истёкшие отмечаются как EXPIRED), GET /organization/api-keys (собственные ключи — только метаданные, никогда хеш/открытый текст; isCurrent отмечает вызывающий ключ). Событие organization.member.joined (приглашение принято, организация создана).

v1.16.0 · 6 сентября 2026 г.

  • Финансы (только чтение): GET /accounts, GET /accounts/{id} (план счетов с видом, подтипом, иерархией, проводимостью, банковскими данными и сальдо — канонически дебет − кредит плюс сальдо для отображения), GET /bookings, GET /bookings/{id} (журнал со строками по счёту/контакту/категории затрат, документами, связями с открытыми позициями, ссылкой на сторно; фильтр по периоду, статусу, счёту, контакту, документу), GET /statements, GET /statements/{id}, GET /statements/{id}/lines (банковские выписки с состоянием строк, привязанным счётом и сводкой по кредитной карте). События finance.booking.created (все пути создания) и finance.booking.reversed. Без записи в v1.

v1.15.0 · 6 сентября 2026 г.

  • Почта/SMS/e-mail: GET/POST /letters (создать письмо, при необходимости сразу сгенерировать PDF), GET/PATCH /letters/{id}, POST /letters/{id}/generate (PDF асинхронно, pdfState), POST /letters/{id}/send (канал EMAIL, POSTAL или BOTH — почтовая отправка через подключённого провайдера платная), GET /letters/{id}/pdf, GET /postal-letters, GET /postal-letters/{id} (очередь со статусом, страницами, стоимостью, отслеживанием), GET/POST /sms, GET /sms/{id} (отправить SMS — платно — и прочитать статус доставки), GET /outbound-emails, GET /outbound-emails/{id} (исходящие письма всех разделов; письма клиентских карт исключены). События letters.letter.sent, letters.postal.submitted/sent/delivered/failed, sms.message.sent/delivered/failed.

v1.14.0 · 6 сентября 2026 г.

  • Договоры/электронная подпись: GET /contract-templates, GET /contract-templates/{id} (шаблон с планом сторон, ключами переменных и HTML), GET/POST /contracts (договор из шаблона: стороны по слотам, название/место/дата, дополнительные переменные; воркер рендерит PDF асинхронно — renderState), GET /contracts/{id}, GET/POST /signature-requests (запрос подписи из PDF-документа со сторонами, при необходимости размещением полей, уровнем подписи, согласием; по умолчанию отправляется сразу), GET /signature-requests/{id}, POST …/send (отправка или повторная отправка; договоры только после рендера), POST …/cancel, GET …/events (цепочка хешей), GET …/pdf (запечатанный экземпляр или оригинал, короткоживущая ссылка). События esign.request.sent/completed/sealed/expired/declined/cancelled. Ссылки для подписи никогда не выдаются.

v1.13.0 · 6 сентября 2026 г.

  • Партнёры: GET /affiliates, GET /affiliates/{id} (партнёр со статусом, видом договора, реферальным кодом, контактным лицом; без банковских/налоговых данных), GET /campaigns, GET /campaigns/{id} (кампания с глубиной, моделью, окном атрибуции, товарами, посадочными страницами, параметром ссылки), GET /affiliate-links (участие партнёр × кампания с кликами и готовыми ссылками по посадочным страницам), GET /conversions, GET /conversions/{id} (конверсия с брутто/комиссией/климатическим взносом/базой, статусом, состоянием оплаты, датами выплат и начислениями по уровню/роли), POST /conversions (сообщить о внешней конверсии — по реферальному коду или купону, идемпотентно по externalRef; та же семантика, что у вебхука конверсий), GET /commissions (начисления, только чтение). События affiliates.conversion.registered (из всех путей приёма: Stripe, купон, вебхук, вручную, API) и affiliates.conversion.settled. Без выплат и кредит-нот.

v1.12.0 · 6 сентября 2026 г.

  • Клиенты (управление практикой, данные о здоровье): GET/POST /clients, GET/PATCH /clients/{id} (карта с номером, статусом, переопределением каналов, периодом сопровождения, сроком хранения), GET/PATCH /clients/{id}/fields (все поля карты с текущим значением; запись нескольких полей с моментом измерения/измерившим/причиной), GET/POST /clients/{id}/measurements (история значений с цепочкой исправлений; запись одного измерения), GET/POST /clients/{id}/messages (переписка с клиентом, сторона практики), GET /clients/{id}/files. Всё только при включении клиентских данных (договор об обработке) + clients:read/clients:write; каждый доступ протоколируется по карте (только идентификаторы). События clients.record.created, clients.record.updated, clients.message.received (только ссылки, без данных о здоровье в вебхуке).

v1.11.0 · 6 сентября 2026 г.

  • Формы: GET /forms, GET /forms/{id} (определение: страницы, поля с ключом/типом/опциями/обязательностью/условиями, блоки матрица/повтор, согласия), GET /forms/{id}/responses, GET /responses/{id}, POST /forms/{id}/responses (серверная отправка без OTP; та же валидация, что у публичной формы; необязательный affiliateId для атрибуции; создаёт потенциального клиента + событие лида). Ответы форм клиентских карт только с включением клиентских данных + clients:read. Событие forms.response.submitted (также для публичных форм и форм воронки; формы клиентских карт только как ссылка).

v1.10.0 · 6 сентября 2026 г.

  • Документы: GET /documents (status, type, taskId/none, contactId, tag, financeRelevant, q, updatedSince), GET /documents/{id}, POST /documents (presigned PUT-URL для прямой загрузки в R2, 5 мин) + POST /documents/{id}/confirm (READY, запускает OCR/ИИ или парсер выписки), GET /documents/{id}/download-url (короткоживущая ссылка с именем файла), PATCH /documents/{id} (название, тип, задача, контакт, теги). Извлечённые ИИ поля в extracted. События documents.document.ready/analyzed/updated.

v1.9.0 · 6 сентября 2026 г.

  • Учёт времени: GET/POST /time-entries, GET/PATCH/DELETE /time-entries/{id}, POST /time-entries/{id}/stop. POST без endTime запускает таймер (один на пользователя; останавливает другие, переводит задачу в IN_PROGRESS). Выставленные записи неизменяемы (409 billed). Фильтры taskId, userId, projectId, from/to, isBillable, isBilled, running, updatedSince. События time.timeEntry.created/updated/deleted.

v1.8.0 · 6 сентября 2026 г.

  • Проекты: GET/POST /projects, GET/PATCH/DELETE /projects/{id} — многоязычное название как у задач, клиент + контактное лицо, родительский проект (без циклов), бюджет времени (минуты, предоплата), период; показатели открытых задач, учтённых и оплачиваемых минут. Фильтры q, customerContactId, parentId (none = верхний уровень), activeOn, updatedSince. События projects.project.created/updated/deleted.

v1.7.0 · 6 сентября 2026 г.

  • Задачи: GET/POST /tasks, GET/PATCH/DELETE /tasks/{id}, POST /tasks/{id}/status, GET/POST /tasks/{id}/comments. Многоязычные название/описание: чтение на языке запроса (?locale или Accept-Language) плюс полный titleI18n; запись строкой или объектом {de,en,ru}, язык организации переводится автоматически. Завершение останавливает таймеры, закрывает наблюдателей и создаёт следующее повторение, как в приложении. События tasks.task.created/updated/completed/deleted, tasks.comment.created.

v1.6.0 · 6 сентября 2026 г.

  • Открытые позиции: GET /open-items (direction, status вкл. open/overdue, contactId, invoiceId, q, updatedSince), GET /open-items/{id} (суммы в центах, скидка, состояние напоминаний, платежи = связанные проводки), POST /open-items/{id}/payments (платёж как проводка «банк на лицевой счёт» вкл. распределение по § 367 открытых расходов на напоминания; частично через amountCents; markOnly для простой смены статуса). Напоминания: GET /dunning/reminders и GET /dunning/reminders/{id} (уровень, требование/сбор/проценты/итого в центах, PDF, ссылка портала). События payments.payment.recorded (все пути оплаты), dunning.reminder.sent, invoices.invoice.overdue (при создании уровня напоминания).

v1.5.0 · 6 сентября 2026 г.

  • Счета: GET /invoices (фильтры status вкл. open/overdue, kind, contactId, orderId, q, updatedSince), GET/POST /invoices, PATCH /invoices/{id} (только черновики — GoBD), POST …/issue (номер, проводка, открытая позиция, PDF + ZUGFeRD), POST …/correct (mode cancel = сторно-документ, mode value = корректировка суммы KOR-…), GET …/pdf (финальный или предпросмотр), GET …/xml (ZUGFeRD XML как application/xml). Суммы в центах + точные десятичные строки; брутто-режим (priceMode GROSS) с брутто-ценами. События invoices.invoice.created/issued/sent/paid/cancelled/corrected — также при оплате через Stripe/чекаут/рассрочку/закрытие открытой позиции.

v1.4.0 · 6 сентября 2026 г.

  • Заказы: GET /orders (фильтры status/draft, contactId, sourceQuoteId, q, updatedSince), GET /orders/{id} (позиции с выставленным/снятым/открытым количеством, разделы, связанные счета, PDF подтверждения), GET /orders/{id}/pdf. POST /quotes/{id}/convert: выставить и принять предложение и превратить его в заказ через маршрутизатор принятия (номер заказа, PDF, автоматическая отправка, при необходимости авансовый счёт); ждёт до 25 с, иначе routing-pending. Событие orders.order.created (источник quote|manual|duplicate).

v1.3.0 · 6 сентября 2026 г.

  • Предложения: GET/POST /quotes, GET/PATCH /quotes/{id} (шапка, позиции, разделы; ссылка на артикул заполняет название/единицу/цену/налог), POST …/issue (номер + ссылка портала + PDF), POST …/send (e-mail с PDF; ждёт до 25 с рендеринга, иначе pdf-pending), POST …/accept и …/decline (от имени клиента; принятие запускает заказ/авансовый счёт), GET …/pdf (статус + URL). Суммы в центах + точная десятичная строка. События quotes.quote.created/updated/sent/accepted/declined — также при принятии в клиентском портале.

v1.2.0 · 6 сентября 2026 г.

  • Артикулы: GET/POST /articles, GET/PATCH /articles/{id} — поиск q, фильтры kind/archived, updatedSince; цены как unitPriceCents + unitPriceExact (четыре знака после запятой), валюта = базовая валюта организации; архивирование через PATCH archived (без DELETE). События articles.article.created/updated. Новый код ошибки feature-not-available (403), если функция недоступна для типа организации.

v1.1.0 · 6 сентября 2026 г.

  • Вебхуки: GET/POST /webhooks, GET/PATCH/DELETE /webhooks/{id}, POST …/rotate-secret, POST …/test, GET …/deliveries, POST …/replay; каталог GET /webhooks/events с …/{type}/sample и …/{type}/recent. Подпись по Standard Webhooks (webhook-id, webhook-timestamp, webhook-signature), повторы через 1 мин/5 мин/30 мин/2 ч/12 ч, endpoint отключается после пяти неудач подряд. Scope webhooks:manage.
  • События: contacts.contact.created/updated/deleted, leads.lead.created, webhooks.test.

v1.0.0 · 6 сентября 2026 г.

  • Первая версия публичного API: ключи (capi_…), scope, ошибки по RFC 9457, курсорная пагинация, Idempotency-Key, лимиты, GET /me.
  • Контакты: GET/POST /contacts, GET/PATCH/DELETE /contacts/{id} — поиск (q), фильтры type/tag, updatedSince; пол определяется ИИ, если не указан.