What the instagram_business_content_publish Scope Actually Grants

What does instagram_business_content_publish grant?

Meta defines instagram_business_content_publish in one sentence in the Permissions Reference: "The instagram_business_content_publish permission allows an app to create organic feed photo and video posts on behalf of a business user."

The allowed usage line adds the boundary: "Manage the organic content creation process for Instagram (for example, post photos and videos) on behalf of an Instagram business account."

Two words in that definition do most of the work. Organic rules out anything paid, so the scope does not touch ads, boosted posts or promotion. On behalf of a business user means the permission only reaches accounts that granted it to your app, and Meta states the limit generally on the Instagram Platform overview: "a permission only allows access to data created by the app user who granted the permission."

The scope also never travels alone. Meta lists one dependency for it, instagram_business_basic, and that dependency is not a formality. Basic carries account identity; publish carries the write. Requesting publish without basic leaves the app with no way to resolve the Instagram user ID that every publishing endpoint needs in its path.

Which endpoints require the scope?

Four, and Meta prints the same permission pair in the requirements table of each reference page.

Endpoint	What it does	Permissions for Instagram Login
POST /<IG_ID>/media	Creates the media container	instagram_business_basic, instagram_business_content_publish
POST /<IG_ID>/media_publish	Publishes the container	instagram_business_basic, instagram_business_content_publish
GET /<IG_CONTAINER_ID>	Reads container status	instagram_business_basic, instagram_business_content_publish
GET /<IG_ID>/content_publishing_limit	Reads current quota usage	instagram_business_basic, instagram_business_content_publish

The third row catches people out. Checking whether a container finished processing is a read, and it still needs the publish scope, because the container is an artefact of publishing rather than a piece of profile data. An app that asked for basic alone can create nothing and can also see nothing about what it failed to create.

The fourth row matters for scheduling. Reading the quota is gated behind the same scope as spending it, so an app cannot check how much room an account has left before asking for permission to post. That is worth knowing when you are building against the container and publish quotas the API enforces per account.

Note what is absent from the list. Nothing about captions, alt text, user tags or locations has its own permission. Those are parameters on POST /<IG_ID>/media, which means the 2,200 character caption limit and its tag sub-rules are enforced by the endpoint, not by a scope you can request separately.

How does it relate to the other Instagram scopes?

It belongs to one of two parallel sets, and which set you use is decided by your login flow rather than by your feature list.

Business Login for Instagram	Facebook Login for Business
instagram_business_basic	instagram_basic
instagram_business_content_publish	instagram_content_publish
instagram_business_manage_comments	instagram_manage_comments
instagram_business_manage_messages	instagram_manage_messages
Human Agent feature	instagram_manage_insights
	pages_show_list, pages_read_engagement
	Human Agent, Instagram Public Content Access

The _business_ infix is the tell. Those scopes exist for apps where users sign in with Instagram credentials and hit graph.instagram.com. The shorter names exist for apps where users sign in with Facebook credentials, the professional account is linked to a Facebook Page, and calls go to graph.facebook.com.

The Facebook Login column carries extra baggage that the Instagram column does not. Publishing through that flow also needs pages_read_engagement, and Meta adds a conditional: if the app user was granted their role on the Page through the Business Manager, the app needs ads_management or ads_read as well. Those are advertising scopes required for an organic post, purely because of how the Page role was assigned.

There is one more asymmetry worth reading before you commit. Meta's Page tasks table maps what a user can do on a Page to what they can grant your app, and Content (PROFILE_PLUS_CREATE_CONTENT) and Full control (PROFILE_PLUS_FULL_CONTROL) both grant instagram_content_publish. No equivalent table exists for instagram_business_content_publish, because Business Login for Instagram has no Page in the middle. Under Facebook Login, a user who loses the Content task on the Page loses your app's ability to publish, without anything changing in your app.

Token lifetimes are shared across both flows. The authorization code is valid for one hour, the short lived access token it becomes is valid for one hour, and the long lived token you exchange it for is valid for 60 days and can be refreshed before expiry. That refresh cycle is the same one behind the 60 day Facebook long lived token, and it is the piece of any Instagram automation setup most likely to break quietly.

Token lifecycle

1

Authorization code. Valid for one hour after login.

2

Short lived access token. Valid for one hour.

3

Long lived access token. Valid for 60 days, refreshable before it expires.

What does App Review ask for?

Two written answers and a screencast, and Meta publishes the exact wording of all three.

The use case description prompt: "Provide specific examples of why your app requires the instagram_business_content_publish permission to create and publish organic feed photo and video posts on behalf of other businesses."

The screencast requirements, quoted in full:

Demonstrate the complete Instagram login process on your app platform, showing how your app user grants your app this permission

Demonstrate creating a new organic feed photo post on behalf of a business user

Show how to add a caption, hashtags, and other metadata, and post to the business user's Instagram feed

Read those as a shot list. The reviewer wants the consent screen on camera, a real post created through your interface, and the caption and hashtag fields filled in before it goes out. A recording that starts after login, or that shows an already published post, misses two of the three requirements.

Review only becomes necessary at a specific threshold, which Meta ties to ownership rather than to scale. Standard Access "is intended for apps that will only be used by people who have roles on them", and "If your app only serves your Instagram professional account or an account you manage, Standard Access is all your app needs." Advanced Access is the level "required if your app serves Instagram professional accounts that you don't own or manage", and it "requires App Review and Business Verification."

So a one account internal poster needs no review. Anything a customer signs into needs review plus business verification, and Meta adds a warning about testing in between: "Because of the limited scope of Standard Access, some features might not work properly until your app has been granted Advanced Access."

One escape hatch exists, and publishing is excluded from it. For apps reviewers cannot test, Meta writes: "If reviewers are unable to test your app because it is behind a private intranet, has no user interface, or has not implemented Facebook Login for Business, you can request approval only for the following permissions: instagram_basic, instagram_manage_comments." Neither publishing scope appears on that list. A headless publisher with no UI has no documented path to Advanced Access for posting.

Why does the scope say feed when the API publishes stories and reels?

Because Meta never updated the permission text to match the endpoint. The scope description has said "organic feed photo and video posts" since it was written, while POST /<IG_ID>/media accepts media_type values of CAROUSEL, REELS and STORIES, and the requirements table on that reference lists this same scope for all of them.

Nothing in the Permissions Reference mentions stories, reels or carousels. Nothing in the media reference restricts the scope to feed posts. The two documents describe the same permission at different widths, and the endpoint is the one that is actually enforced.

The practical consequence is a review consequence rather than a runtime one. Your screencast is graded against the words in the permission reference, and those words ask for a feed photo post. Demonstrating a reel or a story instead means demonstrating something the reviewer's checklist does not name. Record the feed post the requirements ask for, then show the rest.

A second wording mismatch sits next to it. Meta's allowed usage line says "post photos and videos", while the Content Publishing guide's Limitations section says "Filters are not supported" and "Shopping tags are not supported." The scope grants more than the endpoint implements.

Frequently asked questions

What is instagram_business_content_publish?

It is the Instagram Platform permission that, in Meta's words, "allows an app to create organic feed photo and video posts on behalf of a business user." It is the Business Login for Instagram scope, used with the graph.instagram.com host.

Does instagram_business_content_publish need another permission alongside it?

Yes. Meta lists instagram_business_basic as its dependency, and every publishing endpoint's requirements table names both scopes together.

What is the difference between instagram_business_content_publish and instagram_content_publish?

Login flow. The first is granted through Business Login for Instagram, where users sign in with Instagram credentials. The second is granted through Facebook Login for Business and also requires instagram_basic and pages_read_engagement.

Does publishing stories or reels need a different permission?

No. The same scope covers media_type values of REELS, STORIES and CAROUSEL, even though the permission description only mentions feed posts.

Does an app publishing to its own Instagram account need App Review?

No. Meta states that Standard Access is enough if your app "only serves your Instagram professional account or an account you manage." Advanced Access, App Review and Business Verification apply once the app serves accounts you do not own.

Can a headless app get the publishing scope approved?

Not through the private app exception. Meta limits that path to instagram_basic and instagram_manage_comments, and neither publishing scope appears on the list.

Can an app check its content publishing quota before it has the scope?

It cannot. The GET /<IG_ID>/content_publishing_limit endpoint needs the same instagram_business_content_publish scope as the endpoints that spend the quota, so nothing about remaining room is visible until the permission is already granted.

Do captions and hashtags need their own permission?

They do not. Captions, hashtags, alt text, user tags and locations are parameters on POST /<IG_ID>/media rather than separate scopes, so the caption length limit and its tagging rules are enforced by that endpoint, not by any permission requested on its own.

Why does Facebook Login for Business sometimes need an advertising permission just to publish?

Publishing through that flow already needs pages_read_engagement alongside instagram_content_publish and instagram_basic. If the app user's role on the Page came from Business Manager, Meta also requires ads_management or ads_read, a condition tied to how the role was assigned rather than to anything about the post.

What does the App Review screencast for this scope need to show?

Three things: the Instagram login screen where the user grants the permission, an organic feed photo post created live through the app's own interface, and the caption and hashtag fields filled in before the post goes out. A recording that starts after login or shows a post that already published misses two of those three requirements.