Facebook API Publishing Requirements and Breaks

If you would rather not build and maintain that connection, PostWharf, the tool we make, publishes to Facebook Pages for you. You connect a Page once, with nothing to file with Meta and no review to wait out, then publish or schedule with one API call and get a delivery receipt for every post.

Facebook API publishing requirements at a glance

Requirement	What Meta's documentation asks for	What to check in your build
Destination	A Facebook Page, published or unpublished. A personal profile's feed does not accept posts from an app.	Store the Page ID, not the Page name.
Access on the Page	The connecting person can perform the `CREATE_CONTENT` task. Admin access carries every task.	Read the `tasks` array returned for each Page.
Permissions	`pages_manage_posts`, plus its dependencies `pages_read_engagement` and `pages_show_list`.	Compare the scopes granted with the scopes requested.
Token	A Page access token, requested with that person's user access token.	Record which person each Page token came from.
Access level	Standard Access covers people with a role on your app. Everyone else needs Advanced Access, approved per permission in App Review.	Send only the permissions you use to review.
Business verification	Required for Advanced Access. Not required when every user has a role on the app.	Find the Business Manager admin who will complete it.
Scheduling	`published` set to `false` with a `scheduled_publish_time` between 10 minutes and 30 days ahead, per the Pages API Posts guide.	Refuse times outside the window before calling Meta.
Video and Reels	Video goes through the Video API. Reels are limited to 30 API-published posts within a 24-hour moving period.	Count Reels in your own queue.

Pages are the only destination

The Pages API is the set of Graph API endpoints for managing a Page's settings and content, and it is where publishing lives. The matching edge on a person's own profile does not take posts from an app. Reels follow the same rule, and Meta's Reels guide lists Pages as the only place an app can publish them.

So the first requirement is not technical. The brand needs a Page, and that Page can be published or unpublished while you test. If a client has been posting from a founder's personal profile, no permission or token changes that; the content has to move to a Page first. Who owns the Page and who can be added to it is a business-settings question, which our guide to Facebook Business Manager setup covers.

The Page task the connecting person needs

Meta checks tasks, not job titles. When someone uses an app to act on a Page, Meta first checks whether that person has been approved for a task that permits the action. Publishing as the Page is the CREATE_CONTENT task. MODERATE covers replying to and deleting comments, MANAGE covers assigning tasks to other people, ANALYZE covers Insights, and ADVERTISE covers ads. Someone given Admin access to the Page in Facebook's own interface can perform all of them.

Meta's guides differ on how many tasks you need. The Get started guide and the Page Feed reference ask for CREATE_CONTENT to publish. The Posts guide, which also covers updating, replying to and deleting posts, asks for CREATE_CONTENT, MANAGE and MODERATE. For an app that only publishes, CREATE_CONTENT is the one to verify.

You can check this instead of asking. A GET request to /{user-id}/accounts with the person's user access token returns the Pages they have let your app reach, and each entry carries a tasks array. If CREATE_CONTENT is missing for the Page they picked, stop there and say so.

Permissions a publishing app requests

Three permissions do the publishing work, and they come as a set:

pages_manage_posts lets the app create, edit and delete posts on the Page. Meta's permissions reference lists pages_read_engagement and pages_show_list as its dependencies.
pages_read_engagement lets the app read content the Page has posted.
pages_show_list gives the app the list of Pages the person manages, which is what fills the Page picker in your connect flow.

The Page Feed reference, the Video API publishing guide and the Reels guide all name those same three. Other Meta pages add more. The Posts guide, which also covers replies, lists pages_manage_engagement and pages_read_user_engagement, plus publish_video for video posts, and the Get started guide lists pages_manage_metadata. Treat those as optional until a feature of yours needs them: each permission is reviewed on its own, and the review asks for specific examples of why the app needs it.

One rule catches people using Facebook Login for Business: the person must grant every permission the login asks for, or the app is granted none. A long permission list is therefore a risk to the connect flow itself, not only to the review.

Page access tokens versus user tokens

A user access token identifies the person. It is what Facebook Login hands your app, and it is not what you publish with. Publishing to /{page-id}/feed takes a Page access token, which you get by calling /{user-id}/accounts with the user token. Meta describes Page tokens as unique to each combination of Page, person and app, so two admins of one Page never share a token.

Lifetimes depend on how the token was obtained:

A user token from web login is short-lived, about one to two hours.
A long-lived user token, exchanged server-side with your app secret, lasts about 60 days. An expired token cannot be exchanged, so the person has to log in again.
A Page token requested with a long-lived user token has no expiration date, though it can still be invalidated.

Meta warns against depending on those lifetimes staying the same. For a business publishing to Pages in its own business portfolio, a system user access token is the alternative. It is built for automated actions on Pages without a person re-authenticating.

Whichever token you hold, prove the chain once per Page: send a test post to /{page-id}/feed, then GET the same edge and find it. A completed Facebook Login only shows which permissions were granted.

App Review, Advanced Access and business verification

Until an app has Advanced Access, only people with a role on it (administrator, developer or tester) can grant it permissions. Meta calls that Standard Access, and it is enough to publish to your own Pages if everyone who connects one has a role on the app.

Once a customer, a client or anyone else without an app role needs to connect a Page, each permission has to be approved for Advanced Access, permission by permission, through App Review. Meta's Business Verification page states that Advanced Access now requires Business Verification: the app must be connected to a business that has completed it, and until then people from other businesses cannot grant the app its permissions. Apps holding Advanced Access also complete a Data Use Checkup every year.

Verification is completed in Business Manager by an admin of the business, not by a developer on the app, so the right person has to be available. Our guide to social API approval timelines covers how long the Meta steps tend to take next to the other networks.

This is the part PostWharf takes off your list. PostWharf holds the platform relationship for Facebook, so there is nothing for you to file and no review to wait out. Each Page you connect becomes a channel, and you publish to it with one call to the Facebook scheduling API, a wharf post --to facebook command or the web composer. Text is checked against Facebook's 63,206-character limit when the post is created, and a post can carry up to 10 images or 1 video. Pricing is per workspace, with unlimited channels in each one.

The scheduling window the Pages API accepts

A scheduled Page post is an unpublished post with a time attached. You send published as false and add scheduled_publish_time, which Meta accepts as a UNIX timestamp in seconds, an ISO 8601 string or a relative string such as tomorrow. A feed post also needs either a message or a link.

curl -X POST "https://graph.facebook.com/v27.0/{page-id}/feed" \
  -d "message=Doors open at nine" \
  -d "published=false" \
  -d "scheduled_publish_time={unix-timestamp}" \
  -d "access_token={page-access-token}"

The window is where Meta's own pages disagree. Read on 10 November 2026, the Pages API Posts guide says the publish time must be between 10 minutes and 30 days from the request, while the Page Feed reference for the same edge says between 10 minutes and 75 days. Build to the shorter window, or keep later posts in your own queue and hand them to Meta inside it.

Three more limits shape a scheduler:

Photos go to /{page-id}/photos and video goes through the separate Video API, so one "create post" function in your product becomes three kinds of call to Meta.
Reels are capped at 30 API-published posts within a 24-hour moving period, and Meta recommends enforcing that limit in your own app.
An app can only update a Page post that it created.

With PostWharf you add publish_at to the same call you would use to publish now. The post joins a queue that retries on failure, and reading the post back returns one delivery per channel with its status, the live URL once it is published and the error text if it failed. The manual route, and how to confirm the result on the Page, is in our guide to scheduling Facebook posts and verifying delivery.

What breaks after setup, and why

A Facebook connection that worked on day one can stop with no change on your side, and Meta sends no warning: its token guide says an app is not notified when a token becomes invalid. You find out when a request fails.

The Page admin who connected it is removed. This is the break that follows from how Page tokens work. A Page token belongs to one person's relationship with the Page, and Meta checks that person's tasks before each action. When an agency employee leaves, a client tidies up its admin list, or someone is moved to access without CREATE_CONTENT, calls made with their token are refused, and posts waiting in your own queue fail when their time comes. Nothing in your database has changed, which is why it reads as a silent failure.

The person changes their password or logs out of the app. Meta returns error code 190 with subcode 460, and the person has to log in again.

The person removes the app. That is code 190 with subcode 458.

The token expires. Code 190 with subcode 463. This is what happens when a flow keeps a short-lived or 60-day user token and never requests the Page token that has no expiry date.

The defences are cheap. Store who authorised each Page, not only the token. Ask a second person with CREATE_CONTENT to connect important Pages, so one departure is not an outage. Re-read /{user-id}/accounts on a schedule and compare the tasks array with what you saved. Treat code 190 as "needs reconnecting", not as an error to retry.

PostWharf watches for this on a connected Page. A channel whose sign-in has gone is marked as needing reconnection and, unless alert emails are switched off, the workspace's owners are emailed. Each delivery is re-checked after publishing, so a Facebook post removed later stops reporting as live. The Instagram version of these failures, where the linked Page adds one more thing that can come apart, is in our guide to Instagram API publishing requirements.

Sources consulted: Meta for Developers (developers.facebook.com), read 10 November 2026: the Pages API guides, the Page Feed, User Feed and Permissions references, the access token guides, Access Levels, Business Verification, App Roles, Facebook Login for Business, and the Video API and Reels publishing guides. Meta's examples used Graph API v27.0 on that date.

Common questions

Can the Facebook API publish to a personal profile?

No. The feed edge on a personal profile does not accept posts from an app, and Reels can only be published to Pages. A brand that posts from a personal profile needs a Page before any API or scheduling tool can publish for it.

Do I need App Review to post to my own Facebook Page?

Not if everyone who connects the Page has a role on your Meta app: they can grant any permission under Standard Access, and business verification is not required in that case. App Review and business verification apply once people without a role on the app need to connect their Pages.

Do Facebook Page access tokens expire?

A Page token requested with a short-lived user token is short-lived too. One requested with a long-lived user token has no expiration date, but it can still be invalidated, for example when the person changes their password or removes the app.

PostWharf is priced per workspace rather than per connected channel, and every plan carries unlimited channels. See per-brand pricing.