Перейти на сайт

REST API: запись с сайта - клиент, питомец, прием

Эта статья описывает базовый сценарий интеграции сайта с Ветменеджером: найти или создать клиента, добавить питомца и создать запись на прием.

Общая последовательность

1. Найти клиента по телефону или ФИО.

2. Если клиент не найден - создать клиента.

3. Если нужно - создать питомца.

4. Получить цель обращения для приема.

5. Создать прием через `POST /rest/api/Admission`.

6. При необходимости подтвердить прием через `Admission/ConfirmAdmission`.


Поиск клиента

Перед созданием клиента нужно проверить, нет ли его уже в базе.

Метод:

```http
GET /rest/api/client/clientsSearchData?search_query={query}
```


Пример поиска по телефону:

```bash
curl --location --request GET 'https://{DOMAIN NAME}/rest/api/client/clientsSearchData?search_query=79000000000' \
--header 'Content-Type: application/json' \
--header 'X-REST-API-KEY: {REST API KEY}'
```

Поиск выполняется по:

  • фамилии, имени, отчеству клиента
  • номеру телефона
  • email
  • кличке питомца
  • названию породы

Для телефона передавайте только цифры. Номер можно передавать с кодом страны или без кода страны.


Создание клиента

Метод:

```http
POST /rest/api/client
```


Пример:

```bash
curl --location --request POST 'https://{DOMAIN NAME}/rest/api/client' \
--header 'Content-Type: application/json' \
--header 'X-REST-API-KEY: {REST API KEY}' \
--data-raw '{
  "last_name": "Иванов",
  "first_name": "Иван",
  "cell_phone": "79000000000",
  "phone_prefix": "7",
  "city_id": 252,
  "status": "ACTIVE"
}'
```


В интерфейсе Ветменеджера обязательные поля клиента - фамилия и город.

При создании через API минимально рекомендуется передавать:

  • `last_name` - фамилия
  • `cell_phone` - мобильный телефон
  • `phone_prefix` - код страны, если используется
  • `city_id` - город, если известен
  • `status` - обычно `ACTIVE`

Если нужно создать временного клиента, передайте `"status": "TEMPORARY"`.


Мультиклиника

Если в домене несколько филиалов, после создания клиента нужно задать связь клиента с клиникой через модель `clinicsToClients`.

При работе через интерфейс программа делает это автоматически. При работе через API связь нужно создавать самостоятельно.


Питомец

Метод:

```http
POST /rest/api/pet
```

Основные поля питомца:

  • `owner_id` - ID клиента
  • `type_id` - вид питомца
  • `alias` - кличка
  • `breed_id` - порода
  • `sex` - пол
  • `birthday` - дата рождения
  • `status` - обычно `alive`


В OpenAPI поле `breed_id` допускает `null`, но для корректной работы пользовательских сценариев лучше передавать реальную породу из справочника.

Получить список пород: `GET /rest/api/breed`. Получить список видов питомцев: `GET /rest/api/petType`.

Если порода неизвестна, согласуйте с клиникой, какое значение использовать: выбрать подходящую породу из справочника или завести отдельную породу вроде "Метис" / "Без породы".


Создание приема

Метод:

```http
POST /rest/api/Admission
```

При создании приема поле `status` отправлять не нужно: оно всегда устанавливается в `not_confirmed`. Поле `reception_write_channel` по умолчанию - `website`.

Пример:

```bash
curl --location --request POST 'https://{DOMAIN NAME}/rest/api/Admission' \
--header 'Content-Type: application/json' \
--header 'X-REST-API-KEY: {REST API KEY}' \
--data-raw '{
  "type_id": "4",
  "admission_date": "2026-06-25 16:45:00",
  "clinic_id": "1",
  "client_id": "6",
  "patient_id": "3",
  "description": "Запись с сайта",
  "admission_length": "00:15:00",
  "user_id": "1"
}'
```


Обязательные поля:

  • `admission_date` - дата и время приема в формате `YYYY-MM-DD HH:MM:SS`
  • `clinic_id` - ID клиники
  • `client_id` - ID клиента (клиент должен существовать в базе)


Рекомендуемые поля для полноценной записи:

  • `patient_id` - ID питомца
  • `user_id` - ID врача (если не передать, прием привяжется к пользователю с максимальными правами)
  • `type_id` - цель обращения
  • `admission_length` - длительность приема
  • `description` - комментарий

Если на выбранное время у врача уже есть приём, занимающий слот, API вернёт ответ с `time_is_busy: 1` и сообщением `Admission time is busy`, и приём не создастся. Отключить эту проверку при создании нельзя - параметр `without_checking` работает только при редактировании.


Как выбрать type_id

`type_id` - это цель обращения на прием. Его нужно получить из справочника `Тип приема`:

```bash
curl --location -g --request GET 'https://{DOMAIN NAME}/rest/api/ComboManualName?filter=[{"property":"title","value":"Тип приема","operator":"="}]' \
--header 'Content-Type: application/json' \
--header 'X-REST-API-KEY: {REST API KEY}'
```


В ответе будет список `comboManualItems`. В `type_id` нужно передавать значение поля `value` нужной цели обращения.


Нужно ли подтверждать прием

Если запись с сайта должна сначала попасть на проверку администратору, достаточно создать прием. Он будет в статусе `not_confirmed`.

Если интеграция должна сразу подтвердить запись, используйте метод:

```http
POST /rest/api/Admission/ConfirmAdmission
```


Пример:

```bash
curl --location --request POST 'https://{DOMAIN NAME}/rest/api/Admission/ConfirmAdmission' \
--header 'Content-Type: application/json' \
--header 'X-REST-API-KEY: {REST API KEY}' \
--data-raw '{
  "id": 30,
  "user_id": 1,
  "client_id": 6,
  "patient_id": 3,
  "admission_type": 4,
  "clinic_id": 1,
  "admission_date": "2026-06-25 16:45:00",
  "description": "Запись с сайта"
}'
```

Обязательные поля для подтверждения:

  • `id` - ID приема
  • `user_id` - ID врача
  • `client_id` - ID клиента
  • `patient_id` - ID питомца
  • `admission_type` - ID цели обращения
  • `clinic_id` - ID клиники
  • `admission_date` - дата приема

Поле `description` необязательно.


Статусы приема

  • `not_confirmed` - не подтвержденный прием, создан через сторонний сервис
  • `save` - запланированный
  • `directed` - ожидает / направлен на прием
  • `in_treatment` - у врача
  • `accepted` - принятый (прием завершен)
  • `delayed` - просроченный
  • `not_approved` - не подтвержденный из-за неполных данных
  • `deleted` - удаленный


Какие статусы занимают время

При проверке занятости слота прием считается занимающим время, если его статус **не** равен `accepted`, `delayed` или `deleted`.

Занимают время:

  • `not_confirmed`
  • `save`
  • `directed`
  • `in_treatment`
  • `not_approved`


Не занимают время (слот считается свободным):

  • `accepted` - прием уже завершен
  • `delayed` - просроченный
  • `deleted` - удаленный


При редактировании приема параметр `without_checking=1` полностью отключает проверку занятости.

👆 На этом пока всё