Общие сведения
Надёжность и безопасность
Покупка лицензии
Начало работы
Роли в системе
Проекты
Концепции
Компоненты
Инструкции
Задачи
Финансы
Ресурсы
Таймшиты
Клиенты
Вики
Затраты
Отчёты и аналитика
FAQ
Типы отчётов
Тип отчёта «Акты»
Тип отчёта «Баланс отсутствий»
Тип отчёта «Бронирование»
Тип отчёта «Биллинг»
Тип отчёта «Версии проектов»
Тип отчёта «Задачи»
Тип отчёта «Задачи проектов»
Тип отчёта «Затраты»
Тип отчёта «Заявки на затраты»
Тип отчёта «Заявки на отсутствия»
Тип отчёта «История ставок пользователей»
Тип отчёта «Запросы ресурсов»
Тип отчёта «Навыки пользователей»
Тип отчёта «Пользователи»
Тип отчёта «Проводки»
Тип отчёта «Ресурсный план»
Тип отчёта «Ресурсный план (по версиям)»
Тип отчёта «Проекты»
Тип отчёта «Сертификаты пользователей»
Тип отчёта «Счета»
Тип отчёта «Счета (строки)»
Тип отчёта «Таймшиты»
Тип отчёта «Таймшиты детально»
Тип отчёта «Финансы»
Тип отчёта «Структура работ»
Тип отчёта «Центры затрат проектов»
Тип отчёта «Задания воркфлоу»
Тип отчета Клиенты
Тип отчета «Контакты»
Тип отчёта «Сделки»
Тип отчёта «История состояний сделок»
Тип отчёта «Взаимодействия»
Использование отчётов
Группировка данных источника
Группировка данных в отчёте
Типы виджетов
Общие отчёты и шаблоны
Настройка отчёта
Экспорт отчётов
Пользовательские настройки отчёта
Вычисляемые поля
Особые колонки отчётов с временными рядами
Использование панелей мониторинга
Публикация панелей
Фильтры источников данных
Настройка и администрирование
Типовой порядок настройки системы
Язык формул и выражений
On-premises
API
История изменений
Термины и определения

Ограничения

Обновлено: 09.05.2024

Лимиты частоты запросов (Rate Limiting)

Интеграционное API ограничивает количество запросов с одного пользователя и IP-адреса.

Если лимит превышен, сервер возвращает ошибку:

429 Too Many Requests

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

  • не более 500 запросов за 10 секунд на одного пользователя;
  • не более 5 одинаковых GET-запросов за 60 секунд на одного пользователя.

Рекомендации по обработке ошибок при вызове API

Вызов API может завершиться с ошибкой. Основные категории ошибок:

  • транзитные ошибки (transient errors) — временные сбои, например, сетевые проблемы или кратковременная недоступность сервиса;
  • ошибки ограничения частоты запросов — например, HTTP 429 Too Many Requests.

Для продуктовых сред (production) рекомендуется использовать стратегию повторных попыток (Retry Policy).

Рекомендуемый алгоритм

  1. Выполните вызов API.

  2. Если произошла транзитная ошибка или ошибка 429, выполните повторную попытку.

  3. Используйте экспоненциальную задержку (exponential backoff) между попытками.
    Пример последовательности задержек: 100 мс → 500 мс → 1500 мс → 5000 мс.

  4. Ограничьте максимальное количество повторных попыток, чтобы избежать бесконечных циклов.

  5. Организуйте мониторинг и логирование:

    • сам факт повторной попытки не является ошибкой, но должен фиксироваться как диагностический сигнал;
    • если после всех попыток вызов завершился неуспешно, это считается ошибкой. Требуется анализ и, при необходимости, корректировка архитектуры (например, пересмотр SLA, таймаутов или стратегии взаимодействия с API).

Лимит на размер страницы данных

Один запрос возвращает не более 500 сущностей (объектов).

Для постраничной загрузки данных используйте параметры запроса $skip и $top. Чтобы избежать дублирования данных на разных страницах, обязательно применяйте сортировку, например, по полю id.

Если в ответе содержится максимальное количество элементов, в теле ответа OData будет присутствовать свойство nextLink с URL для получения следующей страницы данных.

Ограничение на вычислительную нагрузку

Важно! Каждому абоненту выделяется ограниченный объём вычислительных ресурсов. Чрезмерная нагрузка на API может снизить производительность для других пользователей вашей организации. В таких случаях система мониторинга может автоматически ограничить доступ к API с IP-адреса, вызвавшего нагрузку.

Рекомендации по использованию

  1. Не используйте API как локальную базу данных или службу с неограниченными ресурсами.
  2. Продумывайте архитектуру интеграции. Используйте встроенные возможности: свойства created и modified для фильтрации по времени, серверную фильтрацию и группировку данных.
  3. Помните о назначении API. Интеграционное API не предназначено для выгрузки больших объёмов данных. Для этих целей используйте Reporting API.

Содержание

Лимиты частоты запросов (Rate Limiting) Рекомендации по обработке ошибок при вызове API Рекомендуемый алгоритм Лимит на размер страницы данных Ограничение на вычислительную нагрузку Рекомендации по использованию
Ничего не найдено

Перейти на русскую версию?