Перейти к содержимому

Руководство по коннектору

Подключите GitHub к ИИ-агенту

Подключите работу с репозиториями и задачами к агенту.

Поддерживает OOMOL·

Исходный код проверен 2026-09-09. Примеры сверены с указанной ревизией исходного кода. Это не подтверждение проверки реального API сервиса; ваша версия может отличаться.

Способы аутентификации

  • OAuth 2.0
  • API-ключ

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

Учётные данные и OAuth →

Что проверить у этого коннектора

Пример читает профиль аутентифицированного пользователя GitHub. Убедитесь, что это нужный аккаунт. Успех не подтверждает права на конкретные репозитории или работу других Actions GitHub.

Проверьте Action перед вызовом

Назначение примера

Получение профиля подключённого пользователя GitHub.

Необходимые разрешения Action

  • read:user
  • user:email

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

github.get_current_user
curl -s http://localhost:3000/v1/actions/github.get_current_user

После подключения аккаунта адаптируйте параметры к своим ресурсам. Если включена аутентификация runtime, добавьте его Bearer Token.

HTTP
curl -s -X POST \
  http://localhost:3000/v1/actions/github.get_current_user \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Как читать результат

Ответы HTTP runtime содержат success, message, data и meta. Проверяйте success и выходную схему Action, а не только HTTP-статус. Если метаданные содержат executionId, по нему можно найти журнал с замаскированными секретами. Ниже показан формат ответа, а не результат реального вызова API.

Пример формата ответа
{
  "success": true,
  "message": "OK",
  "data": {},
  "meta": {}
}

Если вызов не удался

  • При ошибке аутентификации проверьте адрес и тип учётных данных: административный доступ защищает /api, Bearer-токен runtime используется для /v1 и /mcp. API-ключ провайдера не заменяет токен runtime.
  • При отказе в доступе проверьте scopes Action, правила Actions и разрешения на подключения. Даже действительный токен может не иметь доступа к выбранному аккаунту.
  • Если результат пуст или ресурс отсутствует, проверьте аккаунт и его права на этот ресурс. Успешная авторизация не открывает все рабочие пространства, каналы и документы.
  • Изучите ошибку и журнал до повтора. Если Action изменяет данные провайдера, сначала проверьте, не завершилась ли операция; не повторяйте запрос вслепую.

Проверка

Наличие в каталоге, локальный исполнитель и проверка API провайдера — разные статусы. Изучите исходный код и результаты проверки нужных Actions.

Исходный код проверен 2026-09-09· Примеры сверены с указанной ревизией исходного кода. Это не подтверждение проверки реального API сервиса; ваша версия может отличаться.

Дальнейшие шаги

Для поддерживаемых провайдеров OOMOL настраивает OAuth-приложения и управляет облачной средой. Вы по-прежнему выбираете аккаунт и подтверждаете его разрешения.

Посмотреть коннекторы →