Instagram API в мобильных приложениях: Graph и Basic Display

Instagram API в мобильных приложениях: Graph и Basic Display

Мы настраиваем Instagram API в мобильных приложениях. Часто клиенты просят «добавьте Instagram», не уточняя детали. А зря: выбор неправильного API съедает недели разработки. Instagram Graph API (для бизнес-аккаунтов) позволяет публиковать контент, управлять комментариями и смотреть аналитику. Instagram Basic Display API (для личных аккаунтов) — только чтение медиа пользователя. Разбираемся на практике.

Правильный выбор API экономит до 40% времени на интеграцию и снижает риски отказов в App Review. На основе 20+ проектов мы гарантируем рабочее решение.

Какой API Instagram выбрать для публикации?

Сразу уточните: нужно ли публиковать в Instagram или только показывать фото? Для чтения подойдёт Basic Display. Для публикации — только Graph API, и он требует бизнес-аккаунта, подключённого к Facebook Page. Наш опыт: более 5 лет работы с Instagram API, 20+ проектов — мы гарантируем правильный выбор.

Сравнение показывает: Graph API лучше, если нужен контроль над контентом. Basic Display — только для «войти через Instagram». Официальная документация Instagram рекомендует Graph API для любого взаимодействия, выходящего за рамки чтения.

Instagram Basic Display API: авторизация и чтение медиа

Подходит для сценария «войти через Instagram и показать свои фото».

Авторизация через OAuth:

https://api.instagram.com/oauth/authorize
  &client_id=YOUR_APP_ID
  &redirect_uri=yourapp://oauth
  &scope=user_profile,user_media
  &response_type=code

Получение медиа:

GET https://graph.instagram.com/me/media
  &fields=id,caption,media_type,media_url,thumbnail_url,timestamp
  &access_token=...

Пагинация через cursor из поля paging.cursors. Токен живёт 60 дней, обновляется через refresh_access_token. Ограничение: нельзя публиковать, комментировать или получать followers. Только чтение своего контента.

Instagram Graph API: публикация сегодня

Для публикации требуется бизнес-аккаунт Instagram, подключённый к Facebook Page, приложение в Facebook Developer Console с правами instagram_content_publish. API стабилен уже несколько лет.

Как получить токен доступа в мобильном приложении?

Instagram Graph API не поддерживает прямую авторизацию без Facebook SDK. Стандартный поток:

• Авторизация через Facebook Login SDK (FBSDKLoginKit на iOS/Android).
• Запрос permission instagram_content_publish, instagram_basic.
• Получение User Access Token Facebook.
• Обмен на long-lived token через бэкенд.

Facebook SDK на iOS — 6 МБ к бинарнику. Альтернатива без SDK — OAuth через ASWebAuthenticationSession / Custom Tab с ручной обработкой. Мы используем SDK в 80% проектов — это быстрее и надёжнее. Подробнее про OAuth можно прочитать на Wikipedia.

Публикация фото: двухшаговый процесс

1. Создаём media container:

POST https://graph.facebook.com/v19.0/{ig-user-id}/media
  &image_url=https://yourserver.com/photo.jpg
  &caption=Подпись к посту #тег
  &access_token=...

Ответ: { "id": "17889615814797203" } — ID контейнера.

2. Публикуем контейнер:

POST https://graph.facebook.com/v19.0/{ig-user-id}/media_publish
  &creation_id=17889615814797203
  &access_token=...

Важно: фото должно быть доступно по публичному HTTPS URL. Instagram скачивает его на свои серверы. Архитектура: клиент загружает фото на S3 → получает публичный URL → передаёт на сервер → сервер вызывает Graph API. Мы гарантируем корректную обработку ошибок и повторные попытки.

Публикация видео (Reels) и каруселей

Тот же двухшаговый поток, но с media_type=REELS и video_url. После создания контейнера нужно дождаться обработки видео — статус проверяется через GET /{container-id}?fields=status_code. Для карусели: три шага — создать item-контейнер для каждого фото, затем carousel-контейнер с children=id1,id2,id3, затем опубликовать.

Ограничения и квоты

• 25 публикаций в сутки на один аккаунт.
• 200 запросов в час на один access token.
• media_url из Basic Display API живёт несколько часов — не кэшируем.
• App Review в Facebook для instagram_content_publish — 5–10 рабочих дней.

Webhooks для событий

Graph API поддерживает webhooks: новый комментарий, новое упоминание, изменение статуса публикации. Настройка через Facebook Developer Console: verify token и callback URL. Требуется HTTPS endpoint. В этом разделе мы подключаем уведомления в реальном времени — ваш сервер получает данные без опросов.

Этапы работ

• Аналитика: определяем нужные API, permissions, архитектуру.
• Регистрация Facebook App + настройка Instagram product.
• Реализация OAuth-потока на клиенте и сервере.
• Разработка основного функционала (чтение, публикация, webhooks).
• Тестирование: интеграционное, нагрузочное.
• Прохождение App Review.
• Деплой и документация.

Сроки

Базовая интеграция (авторизация + чтение медиа) — от 3 дней. С публикацией и webhooks — от 6 дней, плюс время на App Review. Точные сроки и стоимость рассчитываем индивидуально. Закажите консультацию — оценим за 1 рабочий день.

Типичные ошибки при интеграции

• Забывают обновить токен — ошибка 401 после 60 дней.
• Не указывают правильный scope в OAuth — получают 403.
• Пытаются кэшировать media_url дольше нескольких часов.
• Не проходят App Review — не хватает скриншотов функционала.

Свяжитесь с нами для консультации. Получите индивидуальное предложение под ваш проект.

Социальные функции в мобильных приложениях: чат, VoIP, лента и реакции

Мы проектируем чат в приложении не как «просто WebSocket + сообщения», а как систему с оффлайн-доступом, отображением истории при плохом соединении, индикаторами печати, статусами прочтения и push-уведомлениями при закрытом приложении. Наш опыт показывает, что всё это должно работать на Android 8 с 512 MB RAM без ANR — иначе пользователи просто уходят. За последние 5 лет мы внедрили социальные модули в 50+ приложений, от стартапов до enterprise, и знаем, где обычно ломается архитектура. Свяжитесь с нами, чтобы получить аналогичные результаты для вашего продукта.

Как мы подходим к разработке чатов?

Выбор протокола и хранилища — первая точка, где ошибаются. WebSocket, XMPP, или готовый SDK — каждый вариант диктует бюджет времени и надёжность.

• Готовый чат SDK (SendBird, Stream Chat, Cometchat) даёт UI-компоненты, серверную инфраструктуру, push-уведомления и модерацию. Быстро, надёжно, но vendor lock-in и recurrent costs. Для MVP — оптимально.
• Firebase Realtime Database / Firestore — для простых чатов без требований к масштабируемости >100K concurrent users. Realtime Database удобнее для упорядоченных списков сообщений, Firestore — для структурированных данных. Ограничение: typing indicators и presence реализуются отдельно через onDisconnect().
• Собственный бэкенд с WebSocket — полный контроль, максимальная кастомизация. Стек: Node.js + socket.io или Phoenix Channels (Elixir), PostgreSQL + Redis для pub/sub. На мобиле: Starscream (iOS Swift), OkHttp WebSocket (Android), socket_io_client (Flutter). Требует 2–3x времени на разработку, но даёт 0 vendor risk. В одном из проектов мы выбрали кастомный WebSocket и сократили затраты на лицензии на 40% по сравнению с SendBird.

«После внедрения чата наш NPS вырос на 20% — пользователи наконец-то получили мгновенные ответы в офлайне.» — CEO финтех-стартапа

Почему важно продумывать оффлайн-режим заранее?

Оффлайн-режим — самая трудоёмкая часть любого чата. Сообщения сохраняются в SQLite (iOS: GRDB, Android: Room) с локальным ID, синхронизируются при восстановлении соединения. Конфликты при одновременной отправке разрешаются через vector clock или server-timestamp ordering. Если не заложить это в архитектуру с первого спринта, переписывать половину кода придётся за 2–3 недели до релиза. На одном проекте мы сократили время переписки с 4 недель до 1,5, применив cursor-based pagination вместо offset — при вставке новых элементов курсор не сдвигается, пользователь не видит дублирующийся контент. Средняя задержка доставки сообщения после оптимизации составила менее 200 мс.

VoIP: CallKit, ConnectionService и WebRTC

VoIP в мобильном приложении разбивается на два сценария: системный UI (выглядит как звонок телефона) или звонок внутри приложения. CallKit (iOS) интегрируется через CXProvider + CXCallController и позволяет показывать входящий вызов на Lock Screen, работать с Bluetooth и прерывать другие аудио. Плюс: приложение запускается через VoIP push (PKPushKit) даже когда убито — обязательно для приёма звонков.

На Android аналог — ConnectionService API. Интеграция сложнее, поведение варьируется между производителями (Xiaomi, Samsung с их battery optimization агрессивно убивают фоновые процессы). WebRTC — транспортный протокол для P2P медиа. Сигнальный сервер (SDP, ICE candidates) — обычно через тот же WebSocket канал. STUN/TURN обязательны: без TURN ~15–20% пользователей за симметричным NAT не увидят вызов. coturn — open source решение, Twilio NTS и Metered TURN — managed.

Лента и реакции

Бесконечная лента — UICollectionView с UICollectionViewDiffableDataSource на iOS, LazyColumn с Paging 3 на Android. Pagination через cursor-based подход — он не сдвигается при вставке новых элементов, в отличие от offset. Реакции (эмодзи на сообщения): каждая реакция — запись (message_id, user_id, emoji), агрегация на сервере GROUP BY emoji. WebSocket-событие reaction_added обновляет счётчик в реальном времени. Анимация появления — через withSpring (Reanimated) или Core Animation spring. В проекте с социальной сетью мы обслуживали до 80 000 одновременных соединений на одном инстансе — лента оставалась отзывчивой.

Push-уведомления для социальных событий: @mention, ответ, новый подписчик — через APNs и FCM. Для rich notifications (превью медиа) на iOS — Notification Service Extension, который загружает медиа до показа. После внедрения таких уведомлений удержание пользователей выросло на 30%.

Как проходит внедрение социальных функций: пошаговый план

Мы поставляем не только код — вот полный список того, что вы получаете:

1. Проектирование схемы данных (SQLite, Firestore, PostgreSQL) с учётом offline-first и масштабирования до 1M пользователей.
2. Реализация клиент-серверного протокола (WebSocket, REST, GraphQL) с поддержкой reconnection и heartbeat.
3. Интеграция push-уведомлений (APNs, FCM) с генерацией сертификатов и настройкой ключей.
4. Настройка ТURN-серверов или выбор managed-провайдера (например, Twilio NTS) для VoIP.
5. Документация API и схема миграций (включая rollback-план).
6. Доступ к репозиторию, CI/CD (GitHub Actions + Fastlane), TestFlight / Google Play Console.
7. Обучение команды (включающее code review первых 2 спринтов) и передача знаний.
8. On-call поддержка в течение 2 недель после релиза.

Типичные ошибки при разработке чатов и как их избежать

• Отсутствие reconnection стратегии. Клиент просто отключается без очереди неотправленных сообщений. Решение: heartbeat, exponential backoff, локальное хранение исходящих с пометкой pending.
• Использование offset пагинации в ленте. При вставке новых постов пользователь видит дубли — прокрутка сбивается. Решение: cursor-based pagination.
• Игнорирование battery optimization на Android. ConnectionService не доживает до входящего вызова. Решение: foreground service с постоянным уведомлением или интеграция через Firebase Cloud Messaging для пробуждения.
• Ошибка при выборе протокола для чата. Голый WebSocket без протокола поверх — переизобретение велосипеда. Platform-agnostic JSON или MessagePack с type-флагом.

⏱ Сроки ориентировочно

Стоимость рассчитывается индивидуально после анализа вашего технического задания и существующей архитектуры. Свяжитесь с нами для оценки проекта — мы предложим две опции: быстрое внедрение через готовые SDK или полностью кастомизированное решение. Получите консультацию и точную смету в течение 2 рабочих дней. Закажите разработку чата уже сегодня — мы гарантируем корректную работу на Android 8+ и iOS 14+.

WebSocket — Wikipedia · WebRTC — Wikipedia · Firebase Realtime Database — Google