The Meta API was connected and nothing worked

OAuth was green and the credentials were valid, but external profiles still returned nothing. Notes on the layers between a connected badge and working Meta data.

2 min read

There's a special kind of optimism that comes from seeing a green "connected" badge next to an API credential. For a few minutes I believed the hard part of the Meta integration was behind me.

It only worked for my own assets

n8n could read the Facebook Pages I manage and the Instagram professional account connected to Virya. Then I tried to collect public data from external profiles, and every request failed.

OAuth is only the first layer

Access to my own assets proves access to my own assets. It doesn't prove that the application may inspect arbitrary Pages or use Instagram Business Discovery. OAuth, token validity, asset ownership, endpoint permissions and App Review are separate checks, even when the dashboard shows several of them in the same green.

Blaming the data first

Before I got there, I blamed the data. A registry workflow scanned 3,991 CRM rows, created zero targets and reported more than three thousand invalid URLs. That looked believable. The actual cause was my parser swallowing an exception and returning an empty identifier.

I changed the audit output to show extracted URLs, valid and invalid counts, duplicates, reasons and a few examples. The next run produced 500 proper targets: 499 Facebook and one Instagram. A strange ratio, but correct for that sorted batch. The database was messy; the parser was messier.

The Instagram token chain

Instagram added another layer. I first used the user OAuth token directly. The proper chain was user token → managed Facebook Page → Page access token → linked Instagram account → Business Discovery. After fixing that, Meta returned error 10 for a known professional account. Another JavaScript tweak wasn't going to help at that point. The blocker was application access and review.

Keeping tokens out of execution history

Testing also turned up a security mistake of my own: the dynamic Page token travelled through ordinary workflow data, so it appeared in execution history. Convenient, yes. Fine for production, no. Secrets now stay in credentials or an isolated server-side path.

A blocked collector no longer blocks outreach

Most importantly, the blocked collector no longer stops everything else. The CRM already contains websites, public emails, genres, notes and submission routes. Outreach continues from that, while social enrichment is explicitly marked as unavailable.

My integration checklist

My integration checklist now starts with the boring layers: network, authentication, token type, asset ownership, permission, application access, business verification, reviewed feature, and only then the data itself.

A successful OAuth flow got me past the first of those layers. Meta had put several more behind it.

Loading…