inngest-api

Навык inngest-api предназначен для работы с REST API v2 Inngest через raw HTTP, curl или fetch, когда нужного действия нет в CLI либо требуется посмотреть точную форму запроса и ответа. Он охватывает поиск API-документации, OpenAPI v2, Bearer-аутентификацию, production и local base URL, пагинацию, чтение схем и безопасную обработку секретов. Если задачу уже умеет выполнять команда inngest-cli, исходный документ рекомендует предпочесть CLI: он сам связывает target, auth-флаги и endpoint-команды и тем самым уменьшает число ручных параметров. Для актуальной проверки источник направляет к официальным страницам api-docs.inngest.com: обзору API, разделу authentication, llms.txt и OpenAPI-спецификации v2.json. Для сгенерированных описаний endpoint используется markdown-суффикс .md, а если такая страница не отдаёт полную схему, источником истины остаётся OpenAPI. В документе указаны два базовых адреса: облачный https://api.inngest.com/v2 и локальный http://localhost:8288/api/v2. Локальный порт нужно подтвердить по реально запущенному dev server, а не принимать на веру из примера. REST API использует Bearer token. Для скриптов, CI и агентов рекомендуется INNGEST_API_KEY; signing key относится прежде всего к взаимодействию приложения с Inngest и применяется для API-запроса только если это действительно доступный и подходящий credential. Для окружения, отличного от production по умолчанию, нужно использовать environment-scoped ключ или передать X-Inngest-Env. Секреты нельзя печатать, сохранять в логах, вставлять в отчёт или помещать в репозиторий. Пример с curl показывает заголовок Authorization через переменную окружения и не раскрывает значение ключа. При поиске endpoint сначала нужно открыть OpenAPI и вывести из неё метод, путь, query-параметры, заголовки и JSON body. Навык запрещает придумывать поля, которых нет в схеме. Ответы следует разбирать как структурированный JSON; для списков отсутствие data трактуется как пустой список только если в ответе нет ошибки. Если page.hasMore равно true, нужно продолжать по cursor, когда требуются все результаты. Это делает пагинацию частью корректного сценария, а не необязательным улучшением. До mutation следует прочитать и подтвердить account, environment, resource и намерение операции. К side effect в исходнике относятся создание или изменение environments, создание webhooks, sync apps, invocation functions, создание partner account и широкие Insights-запросы, которые могут быть дорогими или шумными. Для них нужно отдельно проверить цель и доступ. Навык охватывает account, environments, keys, webhooks, apps, invocation, runs, traces и Insights, но сам по себе не выдаёт разрешения и не заменяет проверку прав. Перед production-запросом требуется подтвердить текущую документацию, окружение, credential и форму ответа; после запроса следует сообщать только безопасные IDs, имена, статусы, pagination и очищенные ошибки.