fix(facebook): map (#200) permission errors to a curated message

[giladresisi]

What kind of change does this PR introduce?

Bug fix / UX improvement

Why was this change needed?

A customer's Facebook Page posts were failing 100% of the time with a Graph API OAuthException, code 200: (#200) ... requires both pages_read_engagement and pages_manage_posts as an admin with sufficient administrative permission. This happens when the connected Facebook account lacks posting rights on the Page (insufficient page role, or pages_manage_posts unchecked in the granular OAuth dialog) — reconnecting alone doesn't fix it, the user has to fix their page access on Facebook first.

Because FacebookProvider.handleErrors had no mapping for it, the failure surfaced as the Unknown Error placeholder — the failure email told the customer nothing, and they had no way to self-serve.

This adds a curated bad-body mapping on the (#200) marker:

Facebook rejected the post due to missing permissions. Make sure your Facebook account has full content access to the Page, then reconnect the channel.

Per Meta's error-handling docs, codes 200–299 are "API Permission" errors, so (#200) always denotes a permissions problem — the mapping can't mislabel an unrelated failure. The reverse isn't 1-1 (other permission errors use other codes, e.g. 10 or the rest of 200–299; see also this writeup on error 200 causes); those still fall back to the generic message, same as today.

With this mapping, the failure email immediately shows the actionable message, and once #1868 (curated calendar error tooltips) merges, the calendar tooltip surfaces it too — so the user can self-serve: fix their Page access on Facebook, reconnect, repost.

Side effect: the isPresetRejection retry helper matches 'Unknown Error', so a (#200) failure on a preset post previously triggered a pointless second publish attempt without the preset; with the curated message it no longer does.

Update — Instagram too (cd1e40d): the same (#200) body also shows up on the Instagram (Facebook-login) provider, where publishing goes through the Facebook Page linked to the Instagram account (5 occurrences in production since 2026-07-01, all previously surfaced as Unknown Error). InstagramProvider.handleErrors now maps it the same way (non-retryable bad-body, message adjusted to point at the linked Page), placed before the generic '190,' rule; instagram-standalone delegates to the same handleErrors, so it is covered as well.

Other information:

Verified against production data: the failing page had 16/16 posts rejected with this exact error body, including after a fresh reconnect, confirming it's a page-access problem the user must resolve on Facebook's side.

Checklist:

• I have read the CONTRIBUTING guide.
• I have signed the Contributor License Agreement (CLA).
• I confirm I have not used AI to submit this PR or generate code for it.
• I checked that there were no similar issues or PRs already open for this.
• This PR fixes just ONE issue

🤖 Generated with Claude Code

[postiz-agent]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[strix-security]

Strix Security Review

No security issues found.

_{Updated for 522a0f4.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}