The Test Passed. The Feature Was Broken. Here's Why That Happens.

The button was green. The status said published. Instagram showed the post. Facebook showed nothing. The only sign anything was wrong was a 403 buried in a log file [FC].

Every test had passed. The feature was broken anyway.

This is the story of a Meta publishing integration that worked perfectly in testing and failed silently in production. The root cause was not a bug in the code. It was a test that checked the wrong thing.

What Was the Setup?

The feature publishes content to a customer's Facebook Page and connected Instagram account. For Meta that means storing a page access token and posting through the Graph API [FC].

The token was stored. It had every permission needed. The in-app connection test passed. Instagram published cleanly. Facebook returned a 403 on the photo upload [FC].

That combination is the trap. Instagram worked, Facebook did not, and all the permissions were granted. If you have debugged Meta's Graph API you know that "all scopes granted but one endpoint 403s" sends you straight into the permissions documentation for hours [FC].

What Was the Wrong Theory?

The first theory was that the page was owned by a Business Manager in a way that needed a different grant. Token flows were rebuilt. The calls were run by hand in a terminal and kept returning a "190 Malformed" error [FC].

That felt like proof something deep was broken. It was not. A Meta page token is over two hundred characters. It had lost a single character when pasted into the terminal [FC]. The malformed error was the clipboard, not the API.

When a value works in one place and fails in another, suspect the transport before inventing a theory about the system.

What Check Actually Ended It?

The token stored was a user token, not a page token. They look identical. They carry the same scopes [FC].

The user token is happy to read, happy to pass a connection test, and happy to publish to Instagram, because Instagram publishing runs through the user to business to account path. But posting a photo to a Facebook Page needs a real Page token, and there a user token gets a flat 403 [FC].

One API call settled it: GET /me?fields=category. A Page has a category. A user does not, so it returns error 100 [FC]. That single request told in seconds what hours of permission theory could not: the wrong kind of token was stored.

The fix was to generate a proper, non-expiring Page token and reconnect. Facebook published on the next try [FC].

Why Should This Bother You?

The test passed because the test only read. It confirmed the token was valid and had scopes. It never tried the one thing the feature exists to do, which is write a post to the Page [FC].

A read-only check on a write feature is not a test. It is a green light wired to the wrong sensor.

An internal success signal is now treated as a hypothesis, not a result. A green badge, a 200, a "published" status, none of them count until the real end state is verified where it actually lives [FC]. For a publish feature that means the post is visible at its live URL, not that a status column flipped.

This is the same lesson in a different costume as you can't prompt your way out of a hard constraint: the API had a real rule, and no amount of confident tooling around it changed the rule. It is also why build and verification boundaries are kept strict and risky work gets its own isolated lane so a false green cannot quietly ride to production.

What Should You Do If You Are Wiring Up Third-Party Publish Flows?

Do two things. Test the write path, not the read path. And verify the result on the far side, in the place a human would actually look.

The cheapest decisive check beats the most confident theory almost every time.

How Do You Tell a User Token from a Page Token?

They look identical. They carry the same scopes. The only way to tell is to call GET /me?fields=category. A Page returns a category. A user returns error 100 [FC].

Why Did Instagram Work but Facebook Did Not?

Instagram publishing runs through the user to business to account path. A user token is sufficient. Facebook Page photo uploads need a real Page token [FC]. The user token gets a 403.

What Is the Lesson About Terminal Errors?

A Meta page token is over two hundred characters. When it lost a single character in a clipboard paste, the API returned "190 Malformed" [FC]. The error was the transport, not the system. When a value works in one place and fails in another, suspect the transport first.

Questions readers often ask

Q: How do you verify a publish feature actually worked?

Check the result on the far side, in the place a human would actually look. For a publish feature that means the post is visible at its live URL, not that a status column flipped [FC].

Q: What is the difference between a user token and a page token?

They look identical and carry the same scopes. A user token can read and publish to Instagram. A page token is required to post photos to a Facebook Page. The only way to tell is to call GET /me?fields=category. A Page returns a category. A user returns error 100 [FC].

Q: Why did the connection test pass if the token was wrong?

The test only read. It confirmed the token was valid and had scopes. It never tried the one thing the feature exists to do, which is write a post to the Page. A read-only check on a write feature is not a test [FC].