Meta Ads - Feature request: Instagram identity discovery (read-only)

GET surface · Meta · API v1 (spec v1.0.4) · requested 2026-08-17

Problem

Zernio auto-resolves the Instagram identity at ad-create time, but exposes no read surface for the IG identity graph. Today the only IG-related endpoint is GET /v1/accounts?profileId=…&platform=instagram, which lists Instagram posting SocialAccounts on the profile — not the IG identities available to an ad account, and not the Page↔IG linkage that your auto-resolve logic actually consults.

For a profile with one Page and one IG account this is tolerable. For customers with multiple Pages and multiple IG accounts on one profile, it makes identity issues effectively undebuggable through your API:

• We cannot see which IG accounts are connected to a given ad account.

• We cannot see which IG account (if any) is linked to a given Page — i.e. what omitted-instagramAccountId auto-resolve should pick.

• We cannot distinguish a real IG professional account from a Page-Backed Instagram Account (PBIA, the faceless shadow identity), so when an ad renders as the wrong identity we can't tell which wrong identity it is without leaving your platform.

Every such case currently ends with us asking the customer to open Meta Business Manager and read ids back to us — which defeats the purpose of a managed middleware.

Business use case

Support and debugging. When a customer reports "my ads are running under the wrong Instagram name" (or a faceless one), we need to answer three questions from our side, via API, in minutes:

1. Which IG identities exist in this ad account's scope?

2. Which one is linked to the Page the ad uses (what auto-resolve will pick)?

3. Is the identity on the delivered ad a real IG account or a PBIA?

Today none of the three are answerable through Zernio. With multiple Pages/IG accounts on one profile, guessing is not viable.

Request — tier A (minimal)

Ad-account-scoped IG listing. One endpoint, read-only:

GET /v1/ad-accounts/{adAccountId}/instagram-accounts
→ { accounts: [ { igUserId, username, profilePictureUrl?, isPageBacked } ] }

Semantically a proxy of Meta's GET /act_{id}/connected_instagram_accounts (the current IGUser edge; the older /act_{id}/instagram_accounts edge was deprecated Sep 2025). The isPageBacked flag matters: a PBIA has no username and renders as the Page — being able to tell them apart is half of every identity ticket.

This alone would resolve most of our debugging pain.

Request — tier B (full identity graph)

Building on tier A, in rough priority order:

1. Page → IG linkage read. For a Page reachable on the profile (e.g. extend the existing /accounts/{id}/facebook-page payload, or a dedicated endpoint): expose instagramBusinessAccount and connectedInstagramAccount per page. This is exactly the input your omitted-instagramAccountId auto-resolve consults, so it lets integrators predict — and verify — resolution instead of reverse-engineering it from delivered ads.

2. Business-level fallback listing. Many advertisers never wire IG to the ad account directly; the identities live at Business Manager level (/{businessId}/instagram_accounts). Either merge these into the tier-A response with a source: "ad_account" | "business" discriminator, or expose them separately. Without this, tier A returns empty for a large class of real accounts.

Why this fits Zernio's model

All of the above is read-only, ad-account- or profile-scoped, and uses edges already covered by standard Marketing API permissions — no new scopes, no token custody changes on our side. It also directly de-escalates support load on your side: identity mis-resolution reports (like our open one) arrive with the full graph attached instead of requiring anonymized back-and-forth.