Meta App Review for Instagram Content Publishing: a step-by-step walkthrough

Publishing organic feed photos and videos to an Instagram professional account requires Instagram's content-publishing permission — Meta's content-publishing documentation currently names it instagram_business_content_publish. Some older integrations and docs still reference instagram_content_publish; Meta has changed permission names before without much notice, so treat both as worth checking rather than assuming one is permanently retired. If you also publish to the linked Facebook Page, you separately need pages_manage_posts. Each is reviewed and granted independently; passing review for one does not grant the other.

Before submitting anything, confirm the exact permission names on Meta's permissions reference. Request only what your shipped feature actually uses — reviewers check usage against the request, and asking for more than you use is one of the more common ways to get rejected.

You test those permissions with a real token before review. Our guide on how to get an Instagram access token covers the App Dashboard shortcut and the full Business Login for Instagram flow.

A human reviewer opens your app the way a real user would: they need to be able to log in, reach the feature that uses the permission, and see it do what your written use-case description says it does. If the reviewer cannot access or reproduce the flow with their own test credentials, the whole submission is rejected — not just the permission in question.

Two things get checked in parallel: your written use-case description (does the stated purpose match what the permission is actually for) and your screencast (does the recording prove it). App configuration — privacy policy URL, app icon, app category, data-use checkboxes — is validated before a human even looks at your submission; incomplete configuration causes an immediate bounce.

Meta's screen-recording guidelines call for footage that shows how to test each requested permission or feature — in practice that means recording a separate clip per permission rather than combining several into one video, since a reviewer testing one permission should not have to fast-forward past an unrelated flow. Each clip should show, in order: the login or account-connection step, the specific feature that triggers the permission, and clear evidence that the resulting data or action is used only for the purpose you described. Skip the login flow, start already authenticated, or gloss over the consent screen, and reviewers will reject it on that basis alone.

Practical hygiene matters more than production values: full resolution, a visible cursor, an English UI (or captions if not), and a flow the reviewer could repeat themselves with a fresh test account. Do not request a permission for a feature that is not built yet — reviewers need to see it working, not described.

In roughly descending order of frequency: a vague or incomplete screencast (missing steps, unclear consent, permission not actually demonstrated); a use case that does not match the permission requested (e.g. asking for publishing access to describe an analytics-only feature); missing or mismatched app configuration (privacy policy URL, category, data-use declarations); requesting permissions your shipped product does not currently need; and test instructions the reviewer cannot follow — wrong credentials, a broken staging environment, or steps that assume context the reviewer does not have.

None of these are exotic. Most rejections are process failures, not policy disputes — which is good news, because they are fixable by tightening the submission rather than by resubmitting the same evidence and hoping.

Meta does not publish a fixed turnaround guarantee, and the real number moves around: it has been reported anywhere from a few days for a clean, well-prepared submission to several weeks during high-volume periods, and developers have reported the slower end becoming more common over time. Each permission is reviewed on its own clock — requesting Instagram publishing and Page publishing together does not mean both land at once. Build your launch plan around the slower end of whatever range you are currently seeing, not the fastest case you have heard about, and budget time for at least one round of rejection-and-resubmission, which is common even for well-prepared apps.

Because the clock only starts once your app configuration is complete and your screencast is uploaded, the fastest lever you control is preparation: a working staging environment, a finished privacy policy, and a screencast that is filmed against the actual submission, not a rough cut you plan to redo later.

Confirm the exact current permission names against Meta's docs, since they have changed before and will again. Make sure the feature is fully built and reachable by a fresh account with no special role. Write test instructions a stranger could follow with no prior context. Record one focused screencast per permission. And keep your privacy policy URL, app icon, and data-use checkboxes complete before you touch submit — that alone clears a category of instant rejections. Also confirm the business behind the app has cleared Business Verification, because Meta Advanced Access requires a verified business before any permission is approved.

While you wait on review, you do not have to block development: PostGate's sandbox mode runs the full publishing lifecycle — validation, async delivery, target status, webhooks — without calling a real provider, so you can build and test the rest of your integration in parallel with Meta's review clock.