Meta Pixel content_id (Item ID) doesn't match Facebook/Instagram catalog retailer_id (Item Variation ID)

We run a Square Online store with the Meta for Business sales channel connected (Online > Meta for Business). Our Meta catalog match rate (Commerce Manager > Events) is stuck at ~22% because of a content_id mismatch between our Meta Pixel events and our synced catalog.

Root cause: the Meta Pixel events fired by our Square Online storefront (POST to /app/cms/api/v1/sites/{site_id}/facebook/pixel-events) send content_id as the parent Square catalog Item ID. But the Facebook/Instagram catalog Square syncs via the “Square” app data source uses the Item Variation ID as the retailer_id - a different identifier for the same product.

Verified example (captured directly from a live AddToCart pixel event on our storefront):

- Product: “2026 Topps Football Super Box”

- Pixel event content_id: an Item ID (e.g. N3IZ42WP6JAHMIGZ5UNJFMVW)

- Catalog entry for the same product is keyed by its Item Variation ID (e.g. IEKD6BCS5VOSYI6ITTJIFXGE)

Meta’s own Commerce Manager diagnostics flagged additional mismatched content IDs from our pixel, and each one also resolves to a Square Item ID rather than the Item Variation ID the catalog holds - so this isn’t a one-off, it’s systemic. Since most of our products have a single “Regular” variation, this breaks catalog matching for nearly the entire catalog and blocks Advantage+ catalog / dynamic product ads.

I raised this with Square general support chat; they confirmed this needs the engineering team that owns the Meta for Business / pixel-catalog integration, since it’s a code-level ID alignment issue between the /facebook/pixel-events payload and the catalog sync, and pointed me here.

I have exact reproduction details - Meta Business ID, ad account ID, Pixel/Dataset ID, catalog ID, and several more verified Item ID / Item Variation ID pairs - ready to share. I’d rather not post those publicly; happy to provide them if a Square engineer replies here or reaches out.

Is this a known issue, and can someone from the Meta for Business integration team take a look?

We are experiencing the same issue with our Square Online store and Meta for Business integration.

Our Meta catalog is synced directly from Square and currently contains 52 products. Meta Commerce Manager is reporting a catalog match rate of only 46.9%, with Product Views matching at 14.5%, while AddToCart is 92.5% and Purchases are 100%.

We confirmed the mismatch directly in Meta Events Manager Test Events. For example, an AddToCart server event from our Square Online store sent:

content_ids: DBPAMJK7IEUXM4KIT3B6UY3Q

Meta reports that some content IDs being received do not match any product in the Square-connected catalog. Searching another reported content ID directly in the Square-synced Meta catalog also returned “No products found.”

This appears consistent with the issue described in this thread: Square’s storefront/event integration is sending an identifier that does not consistently correspond to the retailer_id/product identifier Square supplies to the Meta catalog.

Could someone from Square’s Meta for Business / Square Online integration team investigate this? Since both the catalog synchronization and the event integration are Square-managed, we would like to know whether this is a known identifier-mapping issue and whether a fix is being worked on.

Thank you!

Square Online storefront behavior, including the Meta for Business channel and the Pixel/Conversions API events it fires, isn’t something we can debug or commit to fixes for here — these forums cover the public Square APIs and SDKs. To be clear though, this isn’t a case for Meta’s support either. Both the catalog sync and the event payload are generated by Square, so Meta has nothing to correct on their side.

The path that reaches the owning team is Square Support, asking them to file a bug against the Square Online Meta for Business integration and referencing this thread. Please keep your Business ID, ad account ID, Pixel/Dataset ID, and catalog ID out of the public thread, and share those only in that case.

On expectations meanwhile: the synced Content IDs and the storefront’s tracking output aren’t editable from the Square Online dashboard, so there isn’t a seller-side workaround that restores catalog matching. Event Setup Tool’s “Don’t include content ID” will quiet Meta’s diagnostics, but it forfeits dynamic/catalog attribution, a mitigation, not a fix. Here are a couple of resources I found as well in case you haven’t seen them.

Sorry I can’t be of more help!

Hi Ashley, I wanted to follow up on this because we followed the exact escalation path you recommended, but unfortunately we still have not been able to get this issue in front of the appropriate engineering team.

Following your recommendation, we contacted Square Support and referenced this thread. Square opened case #122048836 regarding the Square Online / Meta for Business integration and the mismatch between the content_id being sent by Square and the IDs in the Meta catalog.

We were told that the case had been escalated to the Developer Success/Engineering team and that an engineer would contact us by email. That escalation occurred around September 28, and as of today, October 6, we still have not received any email or communication from an engineer.

Today I contacted Square Support again at approximately 1:30 PM simply to obtain the status of that existing escalation. I remained in support chat until shortly after 4:00 PM — more than 2½ hours.

During that time I was transferred repeatedly between agents and departments. I provided case #122048836 multiple times, explained repeatedly that we were not trying to restart troubleshooting, and asked several times to speak with a manager or supervisor. I was repeatedly told I was being connected to Advanced Support or a specialized team, but I never received a clear status on the engineering escalation and never actually reached a manager.

Ultimately, while I was once again being transferred to another specialized team, the chat ended without the issue being resolved.

So at this point, despite following the process you recommended, we still do not know:

• Whether the Square Online engineering team actually received the escalation
• Whether anyone has reviewed case #122048836
• Why we never received the promised engineering email
• What the next step is

Since you originally pointed us toward the correct Square team for this issue, is there anything you can do internally to help get case #122048836 in front of the Square Online / Meta for Business engineering team, or help us determine what happened to the escalation?

We have tried to follow the proper support process, but at this point we have exhausted the normal support channels and still have no technical response.

Thank you again for any help you can provide.

Abdiel D.
Mi Casa Kitchen