Работа с Pyrus через MCP

Подключение

Транспорт — streamable-http. В конфигурацию своего MCP-клиента добавьте адрес сервера и три заголовка:

{
  "mcpServers": {
    "pyrus": {
      "url": "https://mcp.pplus.software/mcp",
      "transport": "streamable-http",
      "headers": {
        "Authorization": "Bearer <токен доступа к серверу>",
        "X-Pyrus-Login": "свой-email@example.com",
        "X-Pyrus-Security-Key": "свой-ключ-Pyrus"
      }
    }
  }
}

Если у вас уже есть действующий токен Pyrus, вместо пары «логин + ключ» пришлите X-Pyrus-Access-Token.

Где взять ключ Pyrus: Настройки → Авторизация → Секретный API ключ в вашем Pyrus. Для бота логином служит его собственный email, а не email того, кто бота завёл.

Два уровня доступа

Их легко перепутать, а лечатся они по-разному. Первый решает, пустят ли вас на сервер. Второй — чьи данные Pyrus вы увидите.

Реквизиты Pyrus сервер читает заново на каждом запросе и нигде не сохраняет. Ваш коллега с тем же токеном доступа увидит свой Pyrus, а не ваш. Права внутри Pyrus остаются вашими: если форма вам закрыта, MCP её не откроет.

Несколько контуров Pyrus

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

{
  "task_id": 372965117,
  "access_token": "<токен из вебхука>",
  "api_url": "https://api.pyrus.com/v4"
}

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

Инструменты

Полный список — tools/list. Ниже сгруппированы те, что нужны чаще других. Метки: чтение запись необратимо

Задачи

Формы, реестры, списки

Люди, роли, входящие

Кроме перечисленного есть справочники (get_catalog, sync_catalog, update_catalog_items), объявления, база знаний и управление участниками — всего 88 инструментов.

Реестры и выборки

Самый частый источник неверных выводов. Прочитайте до того, как поверите цифре, полученной из get_registry.

По умолчанию видна только половина

Как отличить открытые от закрытых

{"form_id": 1504224, "include_archived": true, "format": "csv"}

В JSON ни is_closed, ни close_date не приходит. Если формат менять нельзя, ответ даёт поведение по умолчанию:

Формат CSV

format: "csv" отдаёт реестр таблицей вместо JSON. JSON повторяет id, type и name каждого поля на каждой задаче; CSV называет колонки один раз в шапке. На живой форме из 33 полей 50 задач весили 1 110 006 Б в JSON и 33 988 Б в CSV — в 32,7 раза меньше. Это разница между отказом и ответом с запасом.

Но выбирать формат чаще приходится не по размеру, а по составу колонок — они разные:

Считаете, агрегируете, просматриваете много задач — берите CSV. Нужен шаг маршрута или вложенная структура поля — JSON.

Служебные колонки CSV: task_id, create_date, last_modified_date, close_date, last_note_id. Разделитель по умолчанию — запятая, меняется параметром delimiter. BOM, который Pyrus ставит в начало файла, сервер срезает: первая колонка читается как task_id.

Фильтр по значению поля

Параметр field_filters, ключ — числовой id поля:

{"form_id": 1504224, "include_archived": true,
 "field_filters": {"6": 958621}}

Имена и коды полей Pyrus не принимает — только id. Узнать его можно через get_form с summary: true: поля бывают спрятаны внутри групп, и на измеренной форме так лежали 12 из 45, включая «Этап» и «Открыта / Завершена». summary добирается до вложенных полей так же, как flatten, но не тащит с собой списки вариантов — на большой форме это разница между ответом и отказом.

Нечисловой ключ сервер отклонит с подсказкой. Это сделано намеренно: сам Pyrus на неизвестный фильтр отвечает 200 и полной выборкой, то есть опечатка выглядела бы как успешный, но неотфильтрованный результат.

Потолок 20 000 задач

Ограничение принадлежит Pyrus, а не серверу. Проверено голым HTTP-запросом мимо клиента: item_count больше 20 000 отвергается с 400 items_count_out_of_range, а без item_count приходят те же 20 000. Постраничности нет: offset, skip, page и cursor сервер молча игнорирует и возвращает ту же выборку.

Поэтому результат ровно на потолке отклоняется с ошибкой register_truncated, а не выдаётся как полный. Если вам осознанно нужны последние 20 000 и потеря истории приемлема — передайте allow_truncated: true.

Постраничный обход

Единственный способ пройти большой реестр — окна по датам. Одного прохода обычно мало: на форме с 63 000+ записей целые месяцы сами упирались в потолок и требовали дальнейшего дробления.

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

plan_registry_walk(form_id: 2404991)
→ окон: 4, задач: 47 205, проб: 21
  2026-04-07 … 2026-04-13   17 469
  2026-04-13 … 2026-04-18    3 561
  2026-04-18 … 2026-05-31    8 349
  2026-05-31 … 2026-08-26   17 826

Дальше вызываете get_registry по каждому окну с его created_after и created_before. Пробы намеренно дешёвые — CSV с одним полем, — но каждая всё равно расходует запрос из бюджета Pyrus, поэтому их число ограничено параметром max_probes и указывается в ответе.

Если планировщик вернул unsplit — там сутки, в которые уместилось больше 20 000 задач. Дробить датой дальше некуда, сужайте field_filters.

Чем управляет sort

sort: "id" — единственная сортировка, которую Pyrus здесь поддерживает, и она решает, какие именно 20 000 вам достанутся:

Отсюда дешёвый приём: item_count: 1 вместе с sort: "id" возвращает самую первую задачу формы — быстрый способ узнать, с какой даты начинается её история.

Параметр steps фильтрует по current_step — номеру шага процесса, а не по полю формы с похожим названием.

Поиск по аккаунту

Реестр отвечает про форму: «какие задачи в этой форме». Вопрос «какие задачи у этого человека» или «что я поставил другим» реестром не решается вовсе — обходить формы подряд значит потратить десятки вызовов и всё равно пропустить свободные задачи, которых ни в одной форме нет. Для этого есть find_tasks.

Как спрашивать

find_tasks(author="me")                 — что я поставил другим
find_tasks(responsible="me")            — что висит на мне
find_tasks(participants=["me"])         — где я участник
find_tasks(include_text="счёт")         — текстовый поиск по всему аккаунту
find_tasks(list_ids=[2460973])          — всё из конкретного Списка

Человек задаётся числовым id, почтой сотрудника или словом "me". Почта разворачивается по сотрудникам организации; внешнего адресата по почте не найти — ему нужен id из get_contacts. Фильтры складываются, и хотя бы один обязателен: поиск без фильтров вернул бы произвольную горсть задач аккаунта, неотличимую от найденного, поэтому он отклоняется.

Обход выборки целиком

Своей пагинации у Pyrus нет никакой: ни курсора, ни смещения, ни окон по датам — такие параметры он принимает и игнорирует, проверено поимённо на восьми вариантах имён. Поэтому обход делает сервер: передайте page_size и возвращайте next_cursor, пока он приходит.

find_tasks(author="me", page_size=200)           → 200 задач + next_cursor
find_tasks(author="me", page_size=200, cursor=…)  → следующие 200

Проверено живьём: восемь страниц, 1600 задач, ни одного повтора, по 51 КБ на страницу. Цена честная — каждая страница заново спрашивает у Pyrus всю выборку, своего смещения у него нет. Один лишний запрос на страницу против десятков, если перебирать сотрудников по одному.

Позиция держится последним отданным id, а не порядковым номером: задачи, созданные между страницами, получают большие id и встают выше пройденного места. Курсор помнит фильтры, с которыми начат, и отказывается продолжать, если они изменились. Потолок Pyrus в 10 000 задач обходом не снимается — за ним только сужение, и сервер говорит об этом в поле note.

Две вещи, о которых Pyrus молчит

Что приходит в ответе

Опознание, а не содержимое: id, первые 120 символов текста, ответственный, даты, Списки. Задачу целиком берут через get_task, пачку — через get_tasks. Полей формы поиск не отдаёт и по ним не фильтрует — за ними в реестр.

Не путать с search_tasks

search_tasks, несмотря на имя, поиском по аккаунту не является: это реестр одной формы, нарезанный по датам, и он делегирован get_registry. Сквозной поиск — только find_tasks.

Готовые сценарии поверх поиска — delegated, stale, person_360: они и делают описанные здесь вычитания и проверки.

Метка правки

Пока сервер пишет в задачу, она лежит в вашем личном списке «🤖 AI MCP Pyrus», а сразу после успешного коммита выходит из него. Список приватный — посторонние его не видят.

Список создаётся сам при первой вашей записи, в вашем же Pyrus и по вашим реквизитам. Если он уже есть — находится по точному имени, в том числе внутри дерева; дубликат не заводится.

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

Метка никогда не важнее записи: если список не нашёлся и не создался, правка идёт без метки. Всё поведение гасится переменной PYRUS_TASK_MARKER=0.

Повторяющийся отказ

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

Объём ответов

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

{
  "error": "response_too_large",
  "message": "The result is 36935 KB — about 10806 thousand tokens…
              It held 1687 tasks. Nothing was returned…"
}

Что помогает, по убыванию эффекта (замеры на живых формах):

Приёмы складываются: format: "csv" вместе с field_ids снимает вопрос на большинстве реестров.

Большие формы

Форма тоже может не поместиться — измеренная весила 218 КБ, и почти всё это были списки вариантов у полей-справочников и полей с выбором. У get_form для этого два параметра:

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

Задачи

У задач тот же приём — get_task с параметром include оставляет только названные части (на живой задаче 35 → 20 КБ). Идентификаторы задачи возвращаются всегда.

Отступов в ответах нет

Ответы сериализуются компактно, без пробелов и переносов. На живом реестре это 1 110 006 Б против 509 771 Б — те же данные, вдвое меньше токенов. Читаемость от этого не страдает: JSON разбирает агент, а не человек.

Ответ во внешний канал

Комментарий можно отправить не только в ленту задачи, но и туда, откуда пришло обращение — в мессенджер, почту или виджет. За это отвечает параметр channel в comment_task.

{
  "task_id": 373004711,
  "text": "Заявка принята в работу",
  "channel": {"type": "telegram"}
}

Можно передать и просто строку "telegram" — сервер сам приведёт её к нужному виду. Развёрнутая форма нужна, когда требуется указать конкретных отправителя и получателя: {"type": …, "to": {…}, "from": {…}}.

Допустимые типы

Файлы

Содержимое файлов не проходит через MCP-сервер. Инструменты выдают адрес и токен, а байты вы передаёте напрямую в Pyrus. Поэтому размер файла ограничен только самим Pyrus, а диалог не забивается base64.

Загрузка

1. MCP

   get_upload_target — при желании с параметром name.

   {
     "url": "https://api.pyrus.com/v4/files/upload?name=Чек.jpg",
     "form_field": "file",
     "access_token": "..."
   }

2. Ваш HTTP-запрос

   POST на этот адрес: multipart/form-data, файл в поле file, заголовок Authorization: Bearer с полученным токеном. В ответе — guid.

3. MCP

   Передайте guid в comment_task или create_task в массиве attachments — файл появится в задаче.

Скачивание

1. MCP

   get_file_download_url с числовым file_id вложения (он есть в get_task). Возвращает url, filename и access_token.

2. Ваш HTTP-запрос

   GET по этому адресу с заголовком Authorization: Bearer. Без токена Pyrus отвечает 401.

Версии файлов

Чтобы загруженный файл стал новой версией существующего, а не отдельным вложением, нужен root_id. Для этого attachments принимает не только строки-guid, но и объекты:

Готовый инструмент для этого — attach_new_file_version(task_id, guid, root_id).

Поля типа «файл»

Поле формы с типом file ведёт себя не так, как остальные поля, и это стоит знать заранее.

attach_files_to_field(task_id=1042, field_id=16,
                      file_ids=[449339042, 449339043])

Доступ к формам

get_form_permissions показывает, кто имеет доступ к форме и на каком уровне. change_form_permissions этот доступ меняет.

{"form_id": 123456,
 "permissions": {"1733": "member", "1731": "administrator"}}

Ключ — числовой id сотрудника. Почту и имя Pyrus здесь не принимает; id берут из get_form_permissions (у кого доступ уже есть) или get_contacts (все сотрудники).

Неизвестный уровень Pyrus игнорирует, не возвращая ошибки: опечатка выглядела бы как успешный вызов, ничего не изменивший. Поэтому сервер проверяет уровень у себя и отклоняет посторонние значения — до обращения к Pyrus.

Сотрудники

get_members и get_member читают, create_member заводит, update_member правит данные. Роли — get_roles, create_role, update_role, delete_role (у последнего есть task_receiver_id — кому передать задачи удаляемой роли).

Увольнение и блокировка — разные вещи

Поля карточки

Неполный messenger сервер отклоняет: Pyrus такой объект молча выбрасывает, и вызов выглядел бы успешным, ничего не изменив.

Аватар

set_avatar назначает сотруднику уже загруженный файл по его guid. Сам файл он не передаёт — сначала загрузка (см. Файлы), потом этот вызов.

Награды и боты

Награды

Награда вручается и отзывается сама, когда счётчик сотрудника пересекает порог. Пороги задаются на награду, счётчик — на пару «сотрудник + награда».

set_award_threshold(award_id: 7, grant_threshold: 1, revoke_threshold: 91)
increment_award_counter(member_id: 1261579, award_id: 7)

0 отключает свою сторону. Если работают обе, revoke_threshold должен быть больше grant_threshold — иначе награду отзывало бы сразу после вручения. Такую пару сервер отклоняет, не отправляя.

Прочитать текущее состояние: get_award_threshold(award_id) отдаёт оба порога награды, get_award_counter(member_id, award_id) — счётчик одного человека по одной награде вместе с assignment_date. Даты нет — значит награду он ещё не получал.

Боты

Боты — технические аккаунты для интеграций и вебхуков: get_bots, create_bot, update_bot, delete_bot. У создания обязателен только name.

bot_settings — строка JSON, а не объект: Pyrus хранит её дословно и так же отдаёт боту. Объект сервер отклоняет, потому что API его примет, а настройка молча не заработает.

Телефония

register_call регистрирует звонок: Pyrus либо создаёт задачу на форме телефонии, либо комментирует уже существующую по этому абоненту. Что именно произошло, видно в ответе — is_new_task, рядом task_id и responsible_person.

{"account_id": "uniqueID12345",
 "from_number": "+79774221338", "to_number": "+74953009080",
 "internal_number": "200",
 "mappings": [{"code": "CallStartTime", "value": "2021-12-23T00:11:32Z"}]}

internal_number — это то, как звонок находит владельца: Pyrus ищет сотрудника с таким рабочим телефоном и назначает его ответственным. Без него звонок придёт ни на кого.

Запись разговора

attach_call_record прикрепляет аудио к уже зарегистрированному звонку. Звонок опознаётся по external_id, либо task_id, либо паре from_number + to_number — одного номера недостаточно. Сервер проверяет это до отправки; сам Pyrus ответил бы unrecognized_call_id.

record_file — guid уже загруженного файла, а не сам звук: сначала загрузка (см. Файлы), потом этот вызов. Форматы — ac3, mp3, ogg, wav, wma.

Коды mappings

CallDuration, CallStartTime, CallEndTime, PhoneNumberFrom, PhoneNumberTo, Rating, RatingComment, RatingDate. Прочее сервер отклоняет — здесь, в отличие от большинства проверок, не потому что Pyrus промолчит, а просто чтобы сэкономить обращение: он ответил бы invalid_field_mapping_code.

Отдельно стоит узнавать webhook_is_disabled: расширение выключено в Pyrus, и пока его не включат обратно, ничего доходить не будет.

База знаний

Статьи и темы: get_knowledge_base_structure, get_knowledge_base_entity, create_knowledge_base_entity, update_knowledge_base_entity, delete_knowledge_base_entity, плюс права доступа.

Объявления

Четыре инструмента: get_announcements и get_announcement читают, create_announcement публикует, comment_announcement добавляет комментарий к опубликованному.

Обход порциями

Постраничности у Pyrus нет: offset, skip, page и cursor он проглатывает и отдаёт ту же выборку. Поэтому обход строит сам сервер, а вызывающему остаётся идти по курсору.

Правило одно для обоих: передайте page_size, а дальше возвращайте полученный next_cursor обратно, пока он приходит. Не пришёл — обход закончен. Знать заранее ни размер выборки, ни своё положение в ней не нужно.

get_registry(form_id: 2363325, include_archived: true, page_size: 150)
→ 150 задач + next_cursor
get_registry(form_id: 2363325, include_archived: true, page_size: 150,
             cursor: "…")
→ 149 задач + next_cursor        ← одна отсеяна как повтор границы
…
→ короткая порция, курсора нет   ← конец

Обход реестра работает только с JSON: отсев повтора требует id, а в CSV колонку пришлось бы угадывать. Для выгрузки в CSV есть plan_registry_walk — он делит период на окна, которым перекрытие не нужно вовсе.

Справочник для агента

Знание про Pyrus стоит по-разному в зависимости от того, где оно лежит, и сервер раскладывает его по трём местам.

Страницы

read_guide()              — оглавление: что есть и о чём, на килобайт
read_guide("источники")   — что в каком источнике есть: реестр, календарь, Входящие, поиск
read_guide("реестр")      — выборка одним обходом, include_archived, массовая запись
read_guide("поиск")       — поиск по аккаунту и три его молчаливые ловушки
read_guide("лимиты")      — потолки Pyrus и сервера, молчаливые фильтры

Те же тексты доступны ресурсами: pyrus://guide — оглавление, pyrus://guide/registry — страница. Инструмент продублирован ресурсом не от избытка: ресурсы подтягивает клиент, и не каждый клиент это умеет, а инструмент вызывает сам агент — он работает везде.

Ресурсы

Кроме инструментов и промптов сервер отдаёт ресурсы — данные, про которые решает клиент, а не модель. Список виден дёшево, чтение происходит по требованию.

Справочников немного, меняются они редко, и ответ на «нужен ли мне этот» виден по метаданным — поэтому ресурсы заведены именно для них.

Что сервер говорит при подключении

Кроме списка инструментов сервер отдаёт клиенту instructions — короткий текст, который приходит один раз в ответе на initialize и попадает в контекст модели до первого вызова. Туда вынесено то, что нельзя вывести из докстринга отдельного инструмента.

Текст занимает около 1200 знаков против 74 000 знаков описаний инструментов (перемерено 30.09.2026) — примерно 1,6% того, что клиент и так получает при подключении.

Каждый факт в этом тексте закреплён тестом (tests/test_prompts.py), чтобы его нельзя было потерять при редактуре молча. Верхняя граница длины — тоже тест: текст уходит в каждое подключение, и раздувать его нечем.

Готовые сценарии

Кроме инструментов сервер отдаёт промпты — заготовки сценариев, которые запускает человек, а не модель. В интерфейсе клиента они обычно появляются как слэш-команды.

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

export_register — выгрузить реестр целиком

export_register(form_id, fields?, period?)

Разворачивается в сценарий из четырёх шагов: сузить поля через get_form(summary: true) → спланировать окна через plan_registry_walk → забрать каждое окно через get_registry с CSV и field_ids → склеить.

Существует потому, что наивная выгрузка теряет данные двумя независимыми способами, и ни один не виден в ответе: потолок Pyrus в 20 000 задач и лимит размера ответа сервера. Заодно сценарий напоминает про обязательный include_archived и про то, что close_date есть только в CSV.

Если поля переданы аргументом — совет их искать не выводится; если задан период — он подставляется в вызов планировщика.

inbox — разобрать входящие и календарь

inbox(horizon?, mode?)

Личная приоритезация: оценить входящие, встречи и сроки по своей модели весов, разложить задачи по дереву Списков, отложить лишнее. Считает не сценарий, а score_inbox — промпт держит порядок и правила обращения с человеком.

Приоритет складывается из шести вещей сразу: кто автор, из какой формы задача, где вы в ней (согласующий, ответственный, наблюдатель), в каких списках она уже лежит, какие слова в тексте и когда срок. Каждый вклад возвращается отдельным числом в поле why — чтобы на вопрос «почему это верхняя ступень» был ответ из шести слагаемых, и спорить можно было с правилом, а не с вердиктом.

delegated — что я поручил другим

delegated(person?, narrow?)

Единственный путь к этому вопросу: списка задач в API v4 нет, поэтому поиск идёт по автору через find_tasks. Сам поиск на вопрос не отвечает — он не умеет «автор я и ответственный не я», а автора в ответе не присылает вовсе. Сценарий делает вычитание по responsible.id, группирует по исполнителю и добирает подробности пачкой через get_tasks: замеренный обратный случай — 175 вызовов там, где хватало двух.

stale — что заглохло

stale(days?, person?, act?)

Поручения без движения дольше N дней (по умолчанию 14). Весь отбор делается по modified_date прямо в уже полученном ответе поиска — без единого дополнительного запроса. Перед напоминанием сценарий требует проверить, что тишина настоящая: дату двигает и техническая правка. Писать в Pyrus он начинает только по явному act="напомнить", и веером не пишет — список сначала показывают человеку.

person_360 — всё по человеку

person_360(person, narrow?)

Один вызов поиска отвечает только про одну роль: автор, ответственный и участник — три разных вопроса и три вызова. Сценарий объединяет срезы по task_id с пометкой ролей и запрещает складывать их длины: одна задача законно попадает в несколько срезов. include_closed=true обязателен, иначе считается только открытое, а Pyrus об этом не сообщает.

by_catalog_value — найти задачи по значению справочника

by_catalog_value(form_id, field?, value?)

Главное здесь — граница возможного: сквозного поиска по значению справочника в Pyrus нет, фильтр живёт только внутри одной формы. Сценарий ведёт от get_form(flatten: true) за числовым id поля к get_catalog за item_id строки и дальше к get_registry с include_archived. Фильтровать текстом нельзя — Pyrus отвечает ошибкой; несуществующий item_id даёт честный ноль, поэтому неожиданный ноль сверяют реестром без фильтра.

Сценарий целиком

Задача: взять файл из комментария, подготовить новую редакцию и положить её в поле формы новой версией. Четыре вызова MCP и два ваших HTTP-запроса.

1. MCP · get_task

   Найти вложение: comments[].attachments[], оттуда id и root_id. Заодно — id файлового поля в fields.

2. MCP · get_file_download_url

   Получить ссылку и токен.

3. HTTP · GET

   Скачать файл с заголовком Authorization: Bearer.

4. MCP · get_upload_target

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

5. HTTP · POST

   Загрузить новую редакцию, получить guid.

6. MCP · attach_new_file_version

   Прикрепить с root_id исходного файла — появится версия 2. Если файл нужен именно в поле формы, вместо этого attach_files_to_field с числовым id вложения.

Ограничения

Лимит запросов Pyrus

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

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

Необратимые операции

delete_task и delete_list выполняются без подтверждения и не откатываются. Чтобы просто завершить задачу, используйте close_task — она останется в системе.

Скорость

Обращения к Pyrus идут в фоновых потоках, поэтому долгий запрос одного пользователя не останавливает остальных и не мешает проверке живости сервера. Число одновременных обращений всё же ограничено размером пула, так что на десятках активных пользователей очередь станет заметна.

У каждого обращения есть таймаут: 10 секунд на соединение и 120 на ответ (файлы — 600). Раньше зависший запрос занимал воркер до перезапуска процесса. Если реестр действительно не успевает отрендериться, бюджет поднимается переменной PYRUS_READ_TIMEOUT, но правильнее сузить запрос.

get_tasks экономит обращения между агентом и сервером, но не квоту Pyrus: каждая задача — отдельный запрос. Запрашивайте десятки, не тысячи; при исчерпании лимита пачка останавливается сама и сообщает об этом.

Чего сервер не умеет

• Фильтровать реестр по признаку «задача закрыта» — Pyrus такого фильтра не даёт. Но format: "csv" отдаёт close_date, по которой закрытые отбираются на своей стороне; см. выше.
• Листать реестр по смещению — только окнами по датам.
• Листать поиск — там нет и окон по датам: выборку сужают фильтрами, см. Поиск по аккаунту.
• Искать по значению поля формы сразу по всем формам — фильтр по полю работает только внутри одной формы.
• Фильтровать по имени или коду поля — только по числовому id.
• Очищать поле типа «файл» — значения только добавляются.

Разбор ошибок