pages_manage_posts is the Facebook permission your app needs to create, edit or delete posts on a Facebook Page. Without it, a POST to the Page feed fails with a permission error even when your token looks valid. You get it one of two ways: request it and pass app review, or let a tool that already holds it publish for you.
Your app --(Page token)--> Graph API /{page-id}/feed
|
+-- 200 OK token has pages_manage_posts
|
+-- (#200) token is missing the scope,
or was minted before you added it
What is pages_manage_posts and what does it actually allow?
pages_manage_posts lets a token act on the content of a Page: publish, edit and remove posts, and read the posts your app created.
- Create feed posts, links, photos and video posts on a Page you administer.
- Edit and delete posts the app published.
- Read the posts and engagement your app is responsible for, so you can show and manage them.
It is a Page permission, not a user permission. It rides on a Page access token, which is derived from a user token plus the scopes that user granted. Granting it at the user level is only half the job. The token used in the request has to be the Page token, and that Page token has to be minted after the scope was added. A token generated before you added the scope will never carry it, which is the single most common cause of the error below.
Why your Facebook Pages API call returns a pages_manage_posts permission error
Almost every pages_manage_posts permission error comes down to one of four causes, and they all look the same from the outside.
| Cause | What you see | Fix |
|---|---|---|
| Scope never added to the app | Permission error on every call | Add pages_manage_posts in App Dashboard, then re-mint tokens |
| Stale token, minted before the scope | Works for one developer, fails for another | Log the user out and back in, exchange a fresh Page token |
| User token used instead of Page token | Error even though the scope was granted | Exchange the user token for the Page token and call with that |
| User is not an admin of the Page | Fails on one Page, works on others | Grant the user a Page role with posting rights |
The stale token case explains the classic “works for me, fails for the client” report. You added the scope, your token picked it up, the client’s stored token did not. Their token lives in your database until it expires or they reconnect. Reconnecting is what refreshes the scope set.
How to get a Page access token with pages_manage_posts attached
You need the user token to include pages_manage_posts, then you exchange it for a Page token that inherits the scope.
- Add pages_manage_posts to the login or consent flow your app uses so the user grants it.
- Have the user sign in again, so a fresh user token carries the new scope.
- Call the Page’s accounts edge with that user token to get the Page token for the Page you want to post to.
- Store the Page token per Page, and refresh it when the user reconnects.
- Use the Page token as the access token on every write call.
Two practical notes. First, if the Page shows up in the accounts response but the token you get back fails, debug the token and check which scopes it lists. Second, if you manage several Pages, keep one token per Page, not one token for the whole account. Mixing them is how a post lands on the wrong Page.
pages_manage_posts vs pages_read_engagement: which scope do you need to publish?
Publishing needs pages_manage_posts. pages_read_engagement is the read side, and you usually want both.
| Scope | What it is for | Needed to publish? |
|---|---|---|
| pages_manage_posts | Create, edit and delete Page posts | Yes |
| pages_read_engagement | Read Page content and engagement data | No, but needed to read back what you posted |
| pages_manage_engagement | Moderate comments and engagement on the Page | No, unless you reply to or hide comments |
A scheduling tool that also shows analytics needs pages_read_engagement as well. An app that only fires posts can get by with pages_manage_posts alone, but then it cannot tell you a post failed unless the failure comes back in the publish response.
How to request pages_manage_posts and pass app review
Requesting the scope is easy. Passing review is the part that takes time, because Facebook wants to see the permission in use before granting it broadly.
- Add the permission to your app in the App Dashboard under the Permissions and Features section.
- Record a screencast that shows a real user granting the permission and a real post being published to a Page from inside your product. Reviewers reject screen recordings that skip the login.
- Write the description in plain language: what the app posts, who triggers it, and where the content comes from.
- Submit for review and answer follow up questions in the same thread.
Review times move. Do not plan a launch around a fixed number of days, and do not assume approval. Build a fallback into your schedule, such as drafts in the Page’s Publishing Tools, so work is not lost while you wait.
Can you publish to a Facebook Page without pages_manage_posts or app review?
Yes, if the app doing the publishing already holds the permission and has passed review. You are not the app in that case, you are a user of it.
Creator OS is one of those apps. You connect a Facebook Page once, and Creator OS publishes through its own reviewed integration, so you never create a Facebook developer app, request a scope, or wait on review. The same applies to scheduling, drafts, Reels, Stories, link carousels and comment replies. Creator OS also ships a hosted MCP server and a CLI so an AI agent can run your accounts, and those act under the same permission set your connection already has.
That removes the whole token lifecycle from your plate. There is no Page token to store, no scope to re mint, and no “works for me” gap between your account and your client’s. If you are running multiple clients, each one gets its own workspace and its own scoped key, so one client’s connection cannot post to another’s Page.
How to publish a Page post with pages_manage_posts: a working curl example
With a valid Page token in hand, the call is a single POST to the Page feed. Below is the shape, using a text post as the simplest case.
curl -X POST \
"https://graph.facebook.com/v21.0/{page-id}/feed" \
-d "message=First post from the new scheduler" \
-d "access_token={page-access-token}"
Swap the version for the one your app targets, and keep the token out of shell history in real code. If this returns a permission error, run the token through the debug endpoint first and confirm pages_manage_posts is listed. If it is listed and the call still fails, check the user still has a posting role on that Page, because a role change revokes the token’s ability to act.
For a photo or video post, upload the media first, then publish with the returned media id. If you are wiring this into a broader pipeline, the Creator OS API automation walkthrough covers the same publish then verify pattern, and the Facebook Reels API post covers the video case specifically.
If you would rather skip the Facebook app entirely and post from a terminal today, the CLI takes the same content without a token to manage:
creatoros posts:create --text "First post from the new scheduler" \
--platforms facebook --scheduledAt 2026-03-02T14:00:00Z \
--timezone America/Toronto
The schedule is set, the Page connection you already made supplies the permissions, and the post queues like any other.
Facebook pages_manage_posts FAQ
How do I check if my token has pages_manage_posts?
Run the token through the Graph API debug endpoint and read the scopes list. If pages_manage_posts is absent, the token was minted before the scope was granted and you need a fresh one. Debugging the Page token specifically, not the user token, is what tells you the truth.
Why does pages_manage_posts work for admins but fail for clients?
Because each user’s token carries the scopes they granted at sign in, and a token issued before the scope was added will not have it. Your token is fresh, your client’s stored token is old. Have the client reconnect so a new token is minted and the Page token is reissued.
Do I need pages_manage_posts to schedule posts or only to publish them?
Scheduling is your own queue, so the scope only matters at publish time. If your scheduler stores a post and sends it later, the call that actually hits the Page feed is the one that needs pages_manage_posts. A token that expires between scheduling and publishing fails at the send, not at the queue.
What is the difference between pages_manage_posts and pages_manage_engagement?
pages_manage_posts covers the Page’s own posts: creating, editing, deleting. pages_manage_engagement covers interaction on those posts, such as replying to and moderating comments. A tool that schedules posts and replies to comments needs both.
How long does Facebook app review for pages_manage_posts take in 2026?
Do not plan around a fixed number. Review times vary by app, submission quality and reviewer load, and a rejected submission restarts the clock after you fix the issue. Budget for uncertainty and keep a manual fallback such as Publishing Tools drafts so a campaign does not stall.
Get started with Creator OS: queue Page posts without permission headaches
You do not need to build a Facebook app to post to a Page. Connect the Page once in Creator OS and publish, schedule, reply to comments and read analytics from the web app, the iOS app, the CLI, the API or an AI agent over the hosted MCP server. A creatoros posts:create call or a plain sentence to Claude is enough to queue a Page post, and the Facebook permission work is already done.
Creator OS plans start at $14.99/month for 11 platforms plus Skool, with the API, the MCP server and the CLI included. Start free at creatoros.ca/sign-up. If you want to see the publishing flow in motion first, watch the walkthroughs on the KevBuildsApps YouTube channel and the launch video, then read the post options docs for the per network settings. For scheduling from Claude specifically, see scheduling posts with Claude.
Get started for $0
Free trial for new subscribers. Cancel anytime.