SEO-проекты · token

project Проект: карточка, запуск проверки и прогноз лимитов

Группа project работает с одним SEO-проектом: отдаёт его карточку, ставит на внеплановую проверку позиций, ставит на паузу и снимает с неё, отдаёт трафик и считает прогноз расхода лимитов на 30 дней вперёд. Все методы синхронные — ответ приходит сразу.

Адрес
/projects/api/v1/project/<метод>
Доступ
свои проекты и проекты с выданным доступом
Лимиты
тратит только project/parse

Карточка проекта

GET /projects/api/v1/project/get

Домен, главное зеркало, зеркала-алиасы и статус проекта. С details=1 в ответ добавляются интегральные оценки: внутренняя оптимизация, поведенческие, ссылочная масса и сводная оценка.

Параметры query

  • token string обязательный
    Ключ API из настроек аккаунта — тот же, что key у методов инструментов.
  • project_id int обязательный
    ID проекта. Виден в адресе страницы проекта и в ответе projects/get.
  • details int
    Добавить интегральные оценки проекта.
    0
    только карточка
    1
    карточка и оценки
    По умолчанию 0

Ответ

  • domain string
    Домен проекта.
  • main_mirror string
    Главное зеркало с протоколом.
  • aliases string
    Зеркала-алиасы; пустая строка, если их нет.
  • status string
    Статус проекта: 1 — активен.
  • intopt, pf, extopt, summary number
    Только при details=1: внутренняя оптимизация, поведенческие, ссылочная масса, сводная оценка.

Внеплановая проверка позиций

GET /projects/api/v1/project/parse

Ставит запросы проекта в очередь на съём позиций, не дожидаясь расписания. Если по проекту уже идёт незакрытый апдейт, новая проверка не запускается — в ответе придёт дата начала текущего.

Проверка расходует лимиты по тарифу — столько же, сколько плановый съём по расписанию. Сколько уйдёт за месяц, показывает project/limits-forecast.

Параметры query

  • token string обязательный
    Ключ API из настроек аккаунта — тот же, что key у методов инструментов.
  • project_id int обязательный
    ID проекта. Виден в адресе страницы проекта и в ответе projects/get.

Ответ

  • message string
    Что произошло: проверка запущена (в скобках — число запросов) или уже идёт.

Поставить проект на паузу

GET /projects/api/v1/project/stop

Останавливает плановые проверки проекта и запоминает его расписание, чтобы project/start вернул всё как было. Данные проекта не удаляются.

Параметры query

  • token string обязательный
    Ключ API из настроек аккаунта — тот же, что key у методов инструментов.
  • project_id int обязательный
    ID проекта. Виден в адресе страницы проекта и в ответе projects/get.

Ответ

В result — строка: Project successfully stopped или Project already stopped, если проект уже стоял на паузе.

Снять проект с паузы

GET /projects/api/v1/project/start

Возвращает расписание, которое было до паузы, и проверки снова идут по нему.

Параметры query

  • token string обязательный
    Ключ API из настроек аккаунта — тот же, что key у методов инструментов.
  • project_id int обязательный
    ID проекта. Виден в адресе страницы проекта и в ответе projects/get.

Ответ

В result — Project successfully started или Project already started.

Трафик проекта

GET /projects/api/v1/project/traffic

Визиты по дням, неделям или месяцам: без ss_id — всего по Метрике, с ss_id — из одной поисковой системы. Нужна подключённая к проекту Яндекс Метрика.

Параметры query

  • token string обязательный
    Ключ API из настроек аккаунта — тот же, что key у методов инструментов.
  • project_id int обязательный
    ID проекта. Виден в адресе страницы проекта и в ответе projects/get.
  • from date
    Начало периода, ГГГГ-ММ-ДД. Без него — с первых данных.
  • to date
    Конец периода включительно. Без него — по последний день.
  • ss_id int
    Поисковая система из search-systems/get. Без него — весь трафик по Метрике.
  • grouping string
    Шаг группировки.
    d
    по дням
    w
    по неделям (дата — первый день недели с данными)
    m
    по месяцам (дата — первое число)
    По умолчанию d

Ответ

  • result[].date date
    Дата точки.
  • result[].value int
    Визиты за шаг.

Прогноз расхода лимитов

GET /projects/api/v1/project/limits-forecast

Сколько лимитов спишется по проекту за 30 дней вперёд при текущих настройках. Это то же число, что калькулятор в настройках проекта и колонка «Лимитов за 30 дней» в списке проектов — расчёт один.

Параметры query

  • token string обязательный
    Ключ API из настроек аккаунта — тот же, что key у методов инструментов.
  • project_id int обязательный
    ID проекта. Виден в адресе страницы проекта и в ответе projects/get.

Ответ

  • result.project_id int
    ID проекта из запроса.
  • result.days int
    Горизонт прогноза в днях, всегда 30.
  • result.limits int
    Прогноз расхода лимитов за 30 дней, округлён вверх.

Ошибки

КодСообщениеКогда
50 access error Токен не передан, не найден, или у его владельца нет доступа к проекту.
51 wrong project id Проекта с таким project_id нет (stop, start, limits-forecast).
52 wrong request data traffic: grouping не из d, w, m.
101 no such project! get: проект не найден.

Что входит в прогноз лимитов

СлагаемоеКак считается
Проверка позицийЧисло запросов × стоимость запроса по выбранным поисковым системам и глубине съёма × число проверок за 30 дней по расписанию.
Технические проверки(Число запросов × 9 + 100 при сборе ссылочной массы через KeysSo) × периодичность техпроверок. Считается, только если включены рекомендации.
Отслеживание конкурентов1 лимит на запрос в каждой поисковой системе за проверку, сколько бы доменов ни было в списке. При периодичности «каждый N-й апдейт» делится на N.
Проверка частотЧисло запросов × 2 лимита (1 для точной частоты) × число проверок частот за 30 дней.
UpTime сайтаФиксированные ~2 057 лимитов: проверка кода ответа раз в 21 минуту. Начисляется, если отмечена техпроверка «Общие показатели», заполнено главное зеркало и тариф владельца даёт доступ к UpTime.

Чего в прогнозе нет. Перепроверка скачков позиций: перепроверяются только просевшие фразы, их число заранее неизвестно. Ручные запуски проверок (в том числе через project/parse) и расход инструментов вне проекта тоже не учитываются — прогноз описывает плановый расход по расписанию.

Проект на паузе даёт "limits": 0. Прогноз считается на каждый вызов и не кэшируется: любое изменение настроек сразу отражается в ответе. Фактический расход за период отдаёт project/limits/history в REST API.

Формат ответа

Методы принимают GET и POST, но параметры читаются из query-строки. HTTP-код всегда 200: успех и ошибка различаются полями status и code в теле. project/get и project/parse при успехе отдают данные без обёртки status/result — так сложилось исторически, формат сохранён ради совместимости.

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