API Instagram у мобільних застосунках: Graph та Basic Display

API Instagram у мобільних застосунках: 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 — оптимально. Ліцензія SendBird для проекту з 10К користувачів — ~$400/міс.
• Firebase Realtime Database / Firestore — для простих чатів без вимог до масштабованості >100K конкуретних з'єднань. 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–3× більше, але zero vendor risk. Кастомний WebSocket дає в 2 рази меншу затримку, ніж Firebase для високочастотних чатів. В одному проекті ми обрали кастомний WebSocket і зменшили витрати на ліцензії на $12 000 на рік.

Чому важливо продумувати офлайн-режим заздалегідь?

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

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-повідомлення для соціальних подій: @згадка, відповідь, новий підписник — через APNs та FCM. Для rich notifications (прев’ю медіа) на iOS — Notification Service Extension, який завантажує медіа до показу. Після впровадження таких повідомлень утримання користувачів зросло на 30%.

Що входить в роботу: повний список deliverables

Ми постачаємо не тільки код — ось повний перелік того, що ви отримуєте:

1. Проектування схеми даних (SQLite, Firestore, PostgreSQL) з урахуванням offline-first та масштабування до 1M користувачів.
2. Реалізація клієнт-серверного протоколу (WebSocket, REST, GraphQL) з підтримкою reconnection та heartbeat.
3. Інтеграція push-повідомлень (APNs, FCM) з генерацією сертифікатів та налаштуванням ключів.
4. Налаштування TURN-серверів або вибір 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 — вона в 5 разів стабільніша при частих оновленнях.
• Ігнорування battery optimization на Android. ConnectionService не доживає до вхідного виклику. Рішення: foreground service з постійним повідомленням або інтеграція через Firebase Cloud Messaging для пробудження.
• Голий WebSocket без протоколу поверх. Це винахід велосипеда. Використовуйте platform-agnostic JSON або MessagePack з type-флагом.

Стек технологій, що використовується в типовому проекті:

• iOS: Swift 5.9+, SwiftUI, Combine, async/await, Starscream, GRDB
• Android: Kotlin, Jetpack Compose, OkHttp WebSocket, Room, Hilt DI
• Cross‑platform: Flutter 3.x (Dart) або React Native (TypeScript)
• Backend: Node.js + socket.io або Phoenix (Elixir) + PostgreSQL + Redis
• Push: APNs / FCM з сертифікатами та ключами
• VoIP: WebRTC + coturn TURN server

⏱ Терміни орієнтовно

Вартість розраховується індивідуально після аналізу вашого технічного завдання та існуючої архітектури. Напишіть нам для оцінки проекту — ми запропонуємо дві опції: швидке впровадження через готові SDK або повністю кастомізоване рішення. Отримайте консультацію та точний кошторис протягом 2 робочих днів. Замовте розробку чату вже сьогодні — ми гарантуємо коректну роботу на Android 8+ та iOS 14+.