Google will discontinue support for the Shopping Content API v2.1 ("Content API") on August 18, 2026. All systems integrating with Google Merchant Center (GMC) must migrate to the new Merchant API before that date.
✅ You don't need to do anything. The entire migration is performed automatically by Multifeeds in the backend, following these principles:
Maximum reuse of existing data sources. Every pre-existing Content-API data source is identified and retained — no duplicates, no garbage collection of live data.
Create-new only as a fallback. A brand-new Merchant-API data source is created only when the old Content-API counterpart cannot be found (e.g. it was manually deleted, or a new feed label was configured after the old Content-API datafeed was created).
Smart renaming. Legacy data sources with the Google-provided default name "Content API" are automatically renamed so you can tell them apart by feed label.
Per-label data sources for file-based feeds. A single Shopify feed that has multiple feed labels will now produce one Merchant-API data source per label (see Section 4). This is a structural requirement of the Merchant API.
Feed labels are preserved. Every renamed or newly created data source keeps exactly the same feedLabel you configured — Google matches products the same way as before.
An API feed is one where Multifeeds pushes products directly into GMC via HTTPS API calls — no CSV/TSV file is uploaded to a fetch URL.
In the Content-API era, Google (or the app) typically created a single generic data source named:
Content API
After the migration, whenever Multifeeds detects a legacy "Content API" data source it automatically renames it to:
Content API [FEEDLABEL.MF]
Real-world examples:
Your feed label | Old data source name | New data source name (after auto-rename) |
|
|
|
|
|
|
|
|
|
Why the suffix? Appending
[FEEDLABEL.MF]lets you visually confirm that one data source corresponds to exactly one feed label. This is critical for Google to correctly match products to their label/offer.
If the old Content-API data source cannot be found (e.g. you deleted it manually, or you added a brand-new feed label), Multifeeds provisions a fresh Merchant-API data source using a canonical naming pattern:
{FEED NAME YOU SET IN MULTIFEEDS} [{FEEDLABEL}.MF]
Examples:
KIMONO WORLD EU [DE.MF]
ShoppeViet US [USADS.MF]
Minimalist Japan [JPADS.MF]
Zero action required from you.
Legacy Content API → renamed to Content API [FEEDLABEL.MF].
Brand-new data sources → {feed name} [FEEDLABEL.MF].
Both types run 100% on the Merchant API after migration.
A file-based feed is one where Multifeeds generates a CSV/TSV/XML file, hosts it at a public URL, and Google pulls (fetches) that file into GMC on a schedule.
With the old Content API: Even if your Multifeeds feed was configured for multiple feed labels (e.g. one Google TSV feed serves DE, FR, ES, IT — four labels), Multifeeds + Google only needed one single datafeed (one data source). Google split rows internally by feedLabel inside the file.
The Merchant API enforces a stricter contract:
One feed label ↔ one file data source.
As a direct consequence, a single Multifeeds feed that is configured with N feed labels will map to exactly N Merchant-API file data sources in your GMC account.
Real example: Your feed is named Google TSV - Multi EU and covers three feed labels: DE, FRADS, ESADS.
# in GMC | Feed label | Canonical data source name |
1 | DE |
|
2 | FR |
|
3 | ES |
|
This explains why you may observe more data sources in GMC after the migration than before — this is the correct and expected behavior, not a bug.
If you already had a Content-API file datafeed (for example named FRBE FRBEADS.xml.gz), Multifeeds will:
Locate the old data source by its stored mapping + feed label.
Rename it to the canonical pattern:
{legacy name or Multifeeds feed name} [FEEDLABEL.MF]
Keep the exact same scheduled-fetch URL (Multifeeds still writes the file to the same endpoint).
If no old counterpart exists → create a new file data source using the canonical per-label pattern above.
After migration, navigate to GMC → Data sources and apply these recognition rules:
Rule
How to spot it
The | Every data source Multifeeds touches ends with the suffix |
"Content API" prefix | Reused legacy API data sources start with |
Your feed name as prefix | Newly created data sources start with the exact feed name you typed inside Multifeeds (e.g. |
Type | API feed → type shown as |
No trailing [...MF] suffix → either you created it manually, or another app / partner owns it. Multifeeds will not touch such data sources (no rename, no delete, no refetch).
Has a bracket suffix but NOT .MF] (e.g. .SF]) → belongs to another app. Multifeeds ignores it.
NOT a bug. This is the exact structural consequence of the Merchant-API rule:
1 feed label ↔ 1 data source.
Previously a 4-label file feed shared 1 single Content-API datafeed; now it needs 4 separate Merchant-API data sources. Your product data, approvals and offers are unaffected — Google merges results by feed label internally.
No impact at all. Renaming only affects the display name for human readability. Inside GMC the internal IDs, feedLabel setting, scheduled fetch, approval status and product associations all remain intact. Google only cares about the feedLabel attribute, not the display name.
[...MF] data sources I still see?Safe to delete if the old data source is truly unused (0 products, label was retired).
Do NOT delete if products still show under that old feed / label. After migration Multifeeds only governs [...MF] entries; deleting a legacy non-MF data source with live products could remove those offers. If in doubt, contact Multifeeds support first.
[...MF]) — what should I do?This is rare (can happen if the stored mapping was lost e.g. because you deleted the data source manually months ago). How to resolve:
Trigger a full bulk sync once (Multifeeds → Feeds → "Manual refresh").
If still not renamed, open a support ticket with: your shop origin, merchant ID, and a screenshot of the Data sources page.
[FEED.MF] data sources fails with "Maximum number of data sources reached". What now?Google enforces a default quota of 20 data sources per Merchant Center account. If Multifeeds tries to create label #21, the request is rejected. Solutions (either is fine):
Request a quota increase from Google through the GMC Contact support flow, explicitly mentioning the Merchant-API data source limit.
Consolidate feed labels that you no longer actively use inside Multifeeds. Dropping unused labels from configuration reduces the data-source count.
This is not a migration defect. It is the quota-level consequence of "one label = one data source" under the Merchant API.
Multifeeds never creates names like "Copy of..." or "Backup copy of...". These are typically generated by Google's import tooling or a 3rd-party app. Multifeeds ignores them completely.
No. Google sunset the Content API on August 18, 2026. Multifeeds no longer supports it. Rolling back would stop all feeds cold.