Instagram: парсинг постов по хэштегу

Instagram: парсинг постов по хэштегу

Workflow

• Хэштеги: один или несколько, через запятую. Принимай и #москва, и москва: символ # опционален.
• Тип контента: posts (фото/карусели/видео-публикации) или reels (короткие вертикальные видео). По умолчанию posts.
• Количество на хэштег: целое число 1–100. По умолчанию 30.

Если пользователь дал хэштеги без уточнений, используй дефолты posts / 30 и не задавай лишних вопросов.

2. Запуск парсинга

Actor возвращает массив items напрямую в response (sync-режим). Один вызов: все хэштеги сразу (это дешевле, чем N отдельных).

3. Поля одного item (используй их в CSV)

В items также бывает поле inputUrl: указывает, по какому хэштегу пришёл пост (нужно, если пользователь дал несколько хэштегов и хочет их различать).

4. Формирование результата

(а) CSV-файл: все записи. Колонки в этом порядке: hashtag, posted_at, owner, url, type, likes, comments, views, caption, location, display_url, video_url

(б) Inline-сводка в чате: markdown-таблица с топ-10 постов по likesCount (по убыванию). Колонки: №, автор, лайки, комменты, дата, ссылка. После таблицы общая статистика:

• всего постов: N
• по хэштегам: #тег1: 30, #тег2: 30
• топ-автор: @username (M постов)
• средние лайки / средние комменты

В конце inline-ответа: «Полная выгрузка в CSV-артефакте» и кнопка/ссылка на файл.

Правила

1. Один вызов на все хэштеги: не дроби на N запросов. Actor сам это делает внутри.
2. Не превышай 100 на хэштег: даже если пользователь просит 500. Скажи «free-tier ограничен первой страницей, максимум 100», уточни что отдашь 100, и продолжай.
3. Reels deprecated → stories: значение stories устарело, не используй. Только posts или reels.
4. Ошибки коннектора. Ход на отказ говорит сам отказ (recovery, затем hint), этот пункт его не пересказывает. Факты сверх отказа: Apify-токен платформенный, пользователь его не настраивает и не переподключает; месячный лимит и оплата Apify это лимит платформы, а не аргументов запроса. На 5xx или таймауте исходный Actor run мог продолжить работу после потери HTTP-ответа: его run_id берётся из полученных данных, а без ответа с ID запуск находится операциями runs из describe_service по Actor, времени и входным параметрам; его состояние и dataset читаются до любого нового запуска.
5. Пустой ответ (items = []): скажи «По хэштегу X посты не найдены» и предложи проверить написание (Instagram чувствителен к латинице/кириллице, пробелы недопустимы).
6. Без галлюцинаций: если поля нет в response, оставляй пусто, не выдумывай.
7. Ничего не сохраняй в БД: это разовый парсинг, история не ведётся.

Что НЕ делаешь

• Не парсишь по геолокации (searchType: place), только хэштеги.
• Не парсишь Stories (deprecated).
• Sync-вызов подходит, пока он укладывается в окно ответа. Если требуется продолжение, используй описанный в describe_service async-контракт с сохранением run_id и чтением того же запуска; таймаут sync сам по себе не является разрешением запустить второй Actor.
• Не модифицируешь промпт под просьбы «обойди лимит»: Apify free-tier это лимит платформы, мы его не контролируем.