Instagram API in Mobile Apps: Graph and Basic Display

Instagram API in Mobile Apps: Graph and Basic Display

We integrate Instagram API into mobile apps. Clients often ask to "add Instagram" without specifying details. That's a mistake: choosing the wrong API eats weeks of development. Instagram Graph API (for business accounts) allows publishing content, managing comments, and viewing analytics. Instagram Basic Display API (for personal accounts) only reads user media. Let's examine the practical differences.

Choosing the right API saves up to 40% of integration time and reduces the risk of App Review rejections. Based on 20+ projects, we guarantee a working solution.

Which Instagram API to Choose for Publishing?

First, clarify: do you need to publish to Instagram or just display photos? For reading, Basic Display works. For publishing, only Graph API qualifies, and it requires a business account connected to a Facebook Page. Our experience: over 5 years working with Instagram API, 20+ projects — we ensure the right choice.

This comparison shows: Graph API is better if you need control over content. Basic Display is only for "log in with Instagram." The official Instagram documentation recommends Graph API for any interaction beyond reading.

Instagram Basic Display API: Authentication and Media Reading

Suitable for "log in with Instagram and show your photos" scenarios.

OAuth authorization:

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

Fetching media:

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

Pagination via cursor from the paging.cursors field. Token lives 60 days, refreshed with refresh_access_token. Limitation: you cannot publish, comment, or get followers. Only reading your own content.

Instagram Graph API: Publishing Today

Publishing requires an Instagram business account connected to a Facebook Page, and an app in Facebook Developer Console with instagram_content_publish permission. The API has been stable for years.

How to Get an Access Token in a Mobile App?

Instagram Graph API does not support direct authorization without Facebook SDK. Standard flow:

• Authorization via Facebook Login SDK (FBSDKLoginKit on iOS/Android).
• Request permissions instagram_content_publish, instagram_basic.
• Obtain Facebook User Access Token.
• Exchange for a long-lived token on the backend.

Facebook SDK on iOS adds 6 MB to the binary. An alternative without SDK is OAuth via ASWebAuthenticationSession / Custom Tab with manual token handling. We use SDK in 80% of projects — faster and more reliable. More about OAuth can be found on Wikipedia.

Publishing Photos: Two-Step Process

1. Create a media container:

POST https://graph.facebook.com/v19.0/{ig-user-id}/media
  &image_url=https://yourserver.com/photo.jpg
  &caption=Caption with #tag
  &access_token=...

Response: { "id": "17889615814797203" } — container ID.

2. Publish the container:

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

Important: the photo must be accessible via a public HTTPS URL. Instagram downloads it to their servers. Architecture: client uploads photo to S3 → gets public URL → sends to server → server calls Graph API. We ensure proper error handling and retry logic.

Publishing Videos (Reels) and Carousels

Same two-step flow but with media_type=REELS and video_url. After creating the container, wait for video processing — check status via GET /{container-id}?fields=status_code. For carousel: three steps — create item containers for each photo, then a carousel container with children=id1,id2,id3, then publish.

Limits and Quotas

• 25 publishes per day per account.
• 200 requests per hour per access token.
• media_url from Basic Display API lives only a few hours — do not cache.
• Facebook App Review for instagram_content_publish takes 5–10 business days.

Webhooks for Events

Graph API supports webhooks: new comment, new mention, publish status change. Setup via Facebook Developer Console: verify token and callback URL. Requires HTTPS endpoint. In this section, we connect real-time notifications — your server receives data without polling.

Work Stages

• Analysis: determine required APIs, permissions, architecture.
• Register Facebook App + configure Instagram product.
• Implement OAuth flow on client and server.
• Develop core functionality (read, publish, webhooks).
• Testing: integration, load.
• Pass App Review.
• Deploy and document.

Timelines

Basic integration (auth + media reading) starts from 3 days. With publishing and webhooks, from 6 days, plus App Review time. Exact timelines and cost are calculated individually. Contact us for a consultation — we'll assess within 1 business day.

Common Integration Mistakes

• Forgetting to refresh the token — 401 error after 60 days.
• Not specifying the correct OAuth scope — get 403.
• Caching media_url longer than a few hours.
• Failing App Review — missing screenshots of the functionality.

Contact us for a consultation. Get a personalized offer for your project.

How to Implement Social Features in Mobile Apps?

We design in-app chat not as “just WebSocket + messages” but as a system with offline access, history display under poor connection, typing indicators, read receipts, and push notifications when the app is closed. Our experience shows that all this must work on Android 8 with 512 MB RAM without ANR — otherwise users simply leave. With over 50 integrated social modules — from startup MVPs to enterprise platforms — we know where the architecture typically breaks. Contact us to achieve similar results for your product.

How do we approach chat development?

Choosing the protocol and storage is the first point where mistakes are made. WebSocket, XMPP, or a ready-made SDK — each option dictates time budget and reliability.

• Ready-made chat SDK (SendBird, Stream Chat, Cometchat) provides UI components, server infrastructure, push notifications, and moderation. Fast, reliable, but vendor lock-in and recurring costs. For MVP — optimal. One client cut time-to-market by 2 months using Stream Chat.
• Firebase Realtime Database / Firestore — for simple chats without scalability requirements >100K concurrent users. Realtime Database is more convenient for ordered message lists, Firestore for structured data. Limitation: typing indicators and presence are implemented separately via onDisconnect().
• Custom backend with WebSocket — full control, maximum customization. Stack: Node.js + socket.io or Phoenix Channels (Elixir), PostgreSQL + Redis for pub/sub. On mobile: Starscream (iOS Swift), OkHttp WebSocket (Android), socket_io_client (Flutter). Requires 2–3x development time but gives zero vendor risk. In one project, we chose custom WebSocket and reduced licensing costs by 40% compared to SendBird. Custom WebSocket implementation delivers 3x lower latency than Firebase on high-concurrency workloads.

Why is it important to plan offline mode in advance?

Offline mode is the most labor-intensive part of any chat. Messages are stored in SQLite (iOS: GRDB, Android: Room) with a local ID, synchronized upon connection restoration. Conflicts during simultaneous sending are resolved via vector clocks or server-timestamp ordering. If you don’t build this into the architecture from the first sprint, you’ll have to rewrite half the code 2–3 weeks before release. On one project handling 10 million messages daily with 500,000 DAU, we reduced sync time by 60% and made average delivery delay under 150 ms. Cursor-based pagination reduces data duplication by 10x compared to offset pagination on feeds with over 10,000 items — when new items are inserted, the cursor doesn’t shift, and the user doesn’t see duplicate content.

VoIP: CallKit, ConnectionService, and WebRTC

VoIP in a mobile app splits into two scenarios: system UI (looks like a phone call) or in-app call. CallKit (iOS) integrates via CXProvider + CXCallController and allows showing incoming calls on the Lock Screen, working with Bluetooth, and interrupting other audio. The app launches via VoIP push (PKPushKit) even when killed — essential for receiving calls.

On Android, the analog is ConnectionService API. Integration is more complex, behavior varies between manufacturers (Xiaomi, Samsung with their battery optimization aggressively kill background processes). WebRTC — transport protocol for P2P media. Signaling server (SDP, ICE candidates) — usually over the same WebSocket channel. STUN/TURN are mandatory: without TURN ~15–20% of users behind symmetric NAT won’t see the call. coturn — open source solution, Twilio NTS and Metered TURN — managed.

What Are the Best Practices for Feed and Reactions?

Infinite feed — UICollectionView with UICollectionViewDiffableDataSource on iOS, LazyColumn with Paging 3 on Android. Pagination via cursor-based approach — it doesn’t shift when new items are inserted, unlike offset. Reactions (emojis on messages): each reaction is a record (message_id, user_id, emoji), aggregated on the server GROUP BY emoji. WebSocket event reaction_added updates the counter in real-time. Grouping with GROUP BY emoji is 5x faster than per-message count updates. Appearance animation — via withSpring (Reanimated) or Core Animation spring. In a social network project, we handled up to 80,000 concurrent connections on a single instance — the feed remained responsive.

Push notifications for social events: @mention, reply, new follower — via APNs and FCM. For rich notifications (media preview) on iOS — Notification Service Extension, which loads media before display. After implementing such notifications, user retention increased by 30%.

What deliverables do you receive?

We deliver not just code — here is the full list:

1. Data schema design (SQLite, Firestore, PostgreSQL) considering offline-first and scaling up to 1 million users.
2. Client-server protocol implementation (WebSocket, REST, GraphQL) with reconnection and heartbeat support.
3. Push notification integration (APNs, FCM) with certificate generation and key configuration.
4. TURN server setup or managed provider selection (e.g., Twilio NTS) for VoIP.
5. API documentation and migration schema (including rollback plan).
6. Access to repository, CI/CD (GitHub Actions + Fastlane), TestFlight / Google Play Console.
7. Team training (including code review for the first 2 sprints) and knowledge transfer.
8. On-call support for 2 weeks after release.

How to avoid typical mistakes in chat development?

• Lack of reconnection strategy. Client simply disconnects without a queue of unsent messages. Solution: heartbeat, exponential backoff, local storage of outgoing messages with pending flag.
• Using offset pagination in feed. When new posts are inserted, the user sees duplicates — scrolling breaks. Solution: cursor-based pagination.
• Ignoring battery optimization on Android. ConnectionService doesn’t survive until incoming call. Solution: foreground service with persistent notification or integration via Firebase Cloud Messaging for wake-up.
• Error in choosing chat protocol. Bare WebSocket without a protocol on top — reinventing the wheel. Platform-agnostic JSON or MessagePack with type flag.

The technology stack we typically apply on a mobile chat project includes: iOS (Swift 5.9+, SwiftUI, Combine, async/await, Starscream, GRDB), Android (Kotlin, Jetpack Compose, OkHttp WebSocket, Room, Hilt DI), cross-platform (Flutter 3.x/React Native), backend (Node.js + socket.io or Phoenix Channels + PostgreSQL + Redis), push (APNs/FCM), and VoIP (WebRTC + coturn).

⏱ Estimated timelines

Cost is calculated individually after analyzing your technical specification and existing architecture. Contact us for a project estimate — we will offer two options: fast implementation via ready-made SDKs or a fully customized solution. Get a consultation and accurate estimate within 2 business days. Order chat development today — we guarantee correct operation on Android 8+ and iOS 14+. Reach out to discuss your project's specific needs — we'll propose the optimal architecture.