Skip to content

[Feature Request] Add a native Instagram OAuth provider #429

Description

@huangfangyua01-rakuten

Background

Instagram provides OAuth-authenticated APIs for professional accounts (businesses and creators) to read profile and media data, publish content, and manage comments and direct messages.

OpenConnector currently does not include a native instagram provider, and I could not find an existing Instagram provider request.

There is partial indirect Instagram support through existing providers:

  • unifapi exposes several read-oriented Instagram operations behind a UnifAPI API key.
  • ayrshare includes Instagram as one of its supported social publishing platforms.
  • social_fetch and unipile also cover Instagram through intermediary services.

These integrations can be useful, but they require a third-party platform and do not provide a direct Instagram account connection through a customer-owned Meta / Instagram OAuth application.

Feature request

Please consider adding a native instagram provider backed directly by Meta's official Instagram API with Instagram Login (Business Login for Instagram).

Suggested initial Actions:

Read operations

  • instagram.get_current_user
  • instagram.list_media
  • instagram.get_media
  • instagram.list_media_comments
  • instagram.get_media_insights

User-authorized write operations

  • instagram.publish_media
  • instagram.create_comment
  • instagram.reply_to_comment
  • instagram.send_message

The Actions should preserve useful Instagram identifiers and pagination fields such as Instagram user IDs, media IDs, media types (photo, video, carousel, reel), permalinks, caption text, comment IDs, message thread IDs, and cursor-based pagination cursors.

Responses should remain structured so agents can reliably distinguish users, media, comments, messages, insights metadata, pagination metadata, and API errors.

Authentication

The provider could use customer-owned Meta app credentials for Business Login for Instagram:

  • Instagram App ID (client ID)
  • Instagram App Secret (client secret)
  • Registered redirect URI

The connection flow should use Instagram's Authorization Code flow and support durable access through long-lived token exchange and refresh.

Instagram has provider-specific OAuth requirements that OpenConnector should support explicitly:

  • Authorization via https://www.instagram.com/oauth/authorize
  • Short-lived token exchange via https://api.instagram.com/oauth/access_token
  • Long-lived token exchange via https://graph.instagram.com/access_token
  • Long-lived token refresh via https://graph.instagram.com/refresh_access_token
  • Comma-separated OAuth scopes (for example instagram_business_basic,instagram_business_content_publish)
  • API calls against graph.instagram.com using Instagram User access tokens

OAuth scopes should be limited to those required by the enabled Actions. An initial implementation would likely need:

  • instagram_business_basic
  • instagram_business_content_publish
  • instagram_business_manage_comments
  • instagram_business_manage_messages

OAuth client credentials, access tokens, refresh tokens, and Instagram user identifiers should remain behind OpenConnector's credential boundary and must not appear in catalog metadata or unredacted run logs.

The provider documentation should explain that:

  • only Instagram professional accounts (business or creator) are supported;
  • Meta app registration and permission review may be required before production access;
  • the deprecated Instagram Basic Display API and unofficial scraping endpoints are out of scope.

API and policy boundaries

The provider should use Meta's official Instagram Platform endpoints via graph.instagram.com, rather than scraping Instagram pages or relying on undocumented endpoints.

It should also:

  • respect Meta rate limits and retry conservatively;
  • use standard Instagram media container and publishing semantics where publishing is supported;
  • use standard cursor-based pagination for media, comments, and conversations;
  • avoid persisting Instagram content beyond what OpenConnector requires for execution and bounded run logs;
  • document the operator's responsibility to comply with Meta Platform Terms, Instagram Platform Policy, and applicable data-handling and deletion requirements.

Proposed initial scope boundary

The first version should focus on Instagram Login for the authenticated professional account's own profile, media, publishing, comments, and messages.

The following should remain out of the initial scope:

  • Instagram Basic Display API support;
  • Facebook Login for Business / Page-linked Instagram Graph API flows that require a linked Facebook Page;
  • public-content scraping, hashtag search, or follower/following enumeration through unofficial endpoints;
  • autonomous engagement automation such as bulk liking, following, or unsolicited messaging;
  • ads, commerce, product tagging, partnership ads, and creator marketplace administration;
  • moderator administration beyond explicitly scoped comment and message management;
  • storing or redistributing Instagram datasets.

In particular, follower harvesting, explore-feed browsing, and other read operations available only through intermediary APIs should not be included by default, because they are not part of the official self-authorized Instagram Login surface and conflict with Meta's platform rules.

Why this would be useful

A native Instagram provider would let OpenConnector users:

  • connect an Instagram professional account directly through OAuth;
  • read and publish Instagram content through SDK, CLI, MCP, HTTP, and OpenAPI;
  • manage comments and messages with typed, inspectable Actions and explicit scopes;
  • build social content and community-support workflows while retaining control over their Meta OAuth application.

This would complement the existing indirect UnifAPI and Ayrshare integrations while providing a direct, self-hostable path to Meta's official Instagram API.

References

This is a feature request only; no implementation is included in this issue.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions