Fix Make Facebook publish blocked by error 368

TL;DR: Make's Facebook module fails with 368 because Facebook temporarily blocked the posting identity; clear the block in Facebook's support flow, re-authorize the connection, then retry.

The scenario is fine, the mapping is fine, and the error still lands on every run: (368, OAuthException): Confirm your identity before you can publish as this Page. Teams usually rebuild the Make scenario first. That never helps, because the block sits on the Facebook identity doing the posting, not on the module. The failure is filed in the Automation Error Index with other provider-side blocks that masquerade as scenario bugs.

Why does error 368 block Facebook Page publishing from Make?

Code 368 is Meta's temporary block for policy violations on the Graph API. Meta's error-handling reference lists 368 as "temporarily blocked for policies violations" with the instruction to wait and retry the operation. When the Make Facebook Pages > Create a Post module surfaces it, Facebook refused the publish call before anything in the scenario could matter. The module is the messenger.

The Make community thread (17 posts) pins the confusing part: the reporter completed identity verification in Facebook settings and found no instructions in the Facebook app, yet the error persisted. A sibling thread from 2022 reports the identical string, which proves the failure mode recurs across Make versions and is not a regression in any single release. The clearing path runs through Facebook's account-support and business-integrity flows rather than the Make module, and the same "scenario looks fine" trap shows up in other Make faults such as the scenario that will not trigger.

How to clear the 368 block and publish again?

Work Facebook-side first, Make-side second. Rebuilding mappings before the block clears only burns runs.

1. Confirm which identity Facebook sees. Open the failing module and note whether it posts as the Page itself or as a user on the Page, plus which Page role that user holds. A second Page that posts fine through the same scenario points at the blocked identity, not the connection. Write down the Page name, the posting identity, and the exact error subcode before touching anything.
2. Re-authorize the Make connection. In Make, open the Facebook connection used by the scenario, re-authorize it, and confirm the Page and its publishing permission are still granted on the Facebook side of the OAuth screen. Do not clone the scenario; the same connection object carries the token the module uses, and a stale grant re-triggers the block message even after Facebook clears it.
3. Wait out the temporary window, then retry once. Because 368 is explicitly temporary, pause the scenario rather than hammering retries - repeated blocked publishes in a tight loop read as abuse. Wait, run a single manual test publish, and check the module output before re-enabling the schedule. If the test succeeds, resume; if it returns 368 again, return to step 2 instead of widening the fix to unrelated modules. Make's own Retry error handler covers how to space retries once the block clears.

Run Facebook's identity-confirmation flow to completion. In Facebook, open Account Support or Business Integrity (the names shift by region; both live off the account-quality surface, not the general settings page where verification alone already failed for the reporter). Complete every pending confirmation step there, including any Page-level publishing authorization, until the surface shows no outstanding checks. General settings verification is not the same flow, which is why it had no effect.

Checklist before leaving Facebook:
- No pending identity confirmations in Account Support
- No Page publishing restrictions in Business Integrity
- Posting identity still holds a Page role that can publish

How to verify the block is gone?

Publish one manual test post through the same module and confirm a post id returns instead of the 368 payload. Then check the Page itself shows the post with the expected identity (Page name, not a personal profile). Re-enable the schedule only after that single clean run; two consecutive clean scheduled runs close the incident. If the module instead returns a permission error naming a missing scope, the OAuth grant lost a permission during re-authorization - repeat step 3 and tick every Page permission the module requests.

How to recover when the duplicate still appears?

Three leftovers cover most repeat reports. A different Page posts fine but this one does not: the block is Page-scoped, so run step 2 signed in as an admin of the failing Page rather than a different asset. The error cleared then returned: something in the posting pattern re-tripped the policy filter (identical text posted to several Pages in minutes is the classic trigger); stagger posts and vary first comments. The module now fails with a token error instead of 368: the connection grant expired during the wait, so re-authorize again - this is a new fault, and the Make timeout fix shows the same "second error is a different error" shape.

FAQ

Is error 368 a Make bug?

No. The string, subcode, and remedy all come from Facebook's Graph API; Make surfaces what the API returns. A sibling thread from 2022 with the same string across older Make versions confirms it is provider-side and recurring.

Why did identity verification in Facebook settings not clear it?

Settings verification and the publishing-block review are different flows. The reporter completed the former with no effect because the block clears through Account Support or Business Integrity, where Page publishing authorization actually lives.

How long should I wait before retrying?

Meta documents 368 as temporary without a fixed window. Pause the scenario, complete the support flow, then send one manual test. If it still returns 368, wait longer rather than looping retries, since rapid blocked publishes look like abuse.

Should I rebuild the Make scenario or clone the module?

No. Cloning preserves the blocked identity and the stale grant, so the error follows. Re-authorize the existing connection after Facebook clears the block and test the existing module first.

What if a second Facebook Page publishes fine through the same scenario?

That isolates the block to the first Page's identity or roles. Run the support flow as an admin of the failing Page and confirm its publishing authorization specifically; the working Page proves the scenario and connection shape are sound.