---
title: "Content API to Merchant API Migration"
description: "Content API to Merchant API Migration"
url: https://docs.woolytech.com/en/articles/241-content-api-to-merchant-api-migration
collection: "Google Shopping"
updated: 2026-11-04
language: en
---

# Content API to Merchant API Migration

Content API to Merchant API Migration

* * *

## 1\. Why migrate?

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.

* * *

## 2\. How Multifeeds handles the migration for you

✅ **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.
    

* * *

## 3\. For API feeds: What changes in your GMC?

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.

### 3.1 Existing (Content API) data sources — reused and renamed

In the Content-API era, Google (or the app) typically created a single generic data source named:

```javascript
Content API

```

After the migration, whenever Multifeeds detects a legacy "Content API" data source it **automatically renames it** to:

```javascript
Content API [FEEDLABEL.MF]

```

**Real-world examples:**

<table data-id="0ea8108a-3b80-4efd-968b-b05dbde3963c" style="min-width: 75px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p data-id="83091351-3564-43ad-b7b4-fef98bcd22e3">Your feed label</p></td><td colspan="1" rowspan="1"><p data-id="a8322976-a1c7-4f39-b9cf-6ab636800eef">Old data source name</p></td><td colspan="1" rowspan="1"><p data-id="d791327a-f5b0-4482-982f-bcef994e5244">New data source name (after auto-rename)</p></td></tr><tr><td colspan="1" rowspan="1"><p data-id="a98dd09d-6f47-4ccc-999c-bf3a340988d5"><code>VNADS</code></p></td><td colspan="1" rowspan="1"><p data-id="c6372d6a-9d1f-40d2-bc83-832bf5c9e3c4"><code>Content API</code></p></td><td colspan="1" rowspan="1"><p data-id="d654a26a-252a-400c-95e3-266131c0a36c"><code>Content API [VNADS.MF]</code></p></td></tr><tr><td colspan="1" rowspan="1"><p data-id="c0d7402f-ed06-4a75-8e2f-73e6246ebba7"><code>DE-ES</code></p></td><td colspan="1" rowspan="1"><p data-id="1c114590-4b64-4811-ad97-c0e744ccc4f4"><code>Content API</code></p></td><td colspan="1" rowspan="1"><p data-id="e15cf25c-56d8-405a-bd9e-00016a827508"><code>Content API [DE-ES.MF]</code></p></td></tr><tr><td colspan="1" rowspan="1"><p data-id="57e11509-7a98-4c93-8866-84b69bdb6dcd"><code>UK</code></p></td><td colspan="1" rowspan="1"><p data-id="e51e3f0e-901c-47fb-a361-b14b97b425e2"><code>Content API</code></p></td><td colspan="1" rowspan="1"><p data-id="21d6da82-f451-4eb4-89bc-fc8a794177a2"><code>Content API [UK.MF]</code></p></td></tr></tbody></table>

> 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.

### 3.2 Newly created (Merchant API) data sources

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:

```javascript
{FEED NAME YOU SET IN MULTIFEEDS} [{FEEDLABEL}.MF]

```

**Examples:**

```javascript
KIMONO WORLD EU [DE.MF]
ShoppeViet US [USADS.MF]
Minimalist Japan [JPADS.MF]

```

### 3.3 API feeds — summary

-   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.
    

* * *

## 4\. For file-based feeds (CSV / TSV / XML): What changes?

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.

### 4.1 Before (Content API): 1 feed = 1 single datafeed

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.

### 4.2 After (Merchant API): 1 feed label = 1 data source

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`.

<table data-id="3e192f38-e307-4cc2-ba1d-517c6d440811" style="min-width: 75px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p data-id="46e9f9d3-89f5-47a8-ab64-6575bc7d45eb"># in GMC</p></td><td colspan="1" rowspan="1"><p data-id="24202df6-f83f-437a-9ed6-5115122a0267">Feed label</p></td><td colspan="1" rowspan="1"><p data-id="c10367ce-7c31-4ad4-b75c-423eaed86774">Canonical data source name</p></td></tr><tr><td colspan="1" rowspan="1"><p data-id="d0e43a37-8079-4efd-b53f-cddb5b16d632">1</p></td><td colspan="1" rowspan="1"><p data-id="3c7fc493-bd68-4d9c-83fb-4e61fd50e276">DE</p></td><td colspan="1" rowspan="1"><p data-id="cefe8d89-21b0-4935-bf91-44f48c0ace73"><code>Google TSV - Multi EU [DE.MF]</code></p></td></tr><tr><td colspan="1" rowspan="1"><p data-id="d5ce9a15-fbae-4f25-9d60-df683ffb8f63">2</p></td><td colspan="1" rowspan="1"><p data-id="7eea41b0-6a1f-413a-968c-782726a6cd9e">FR</p></td><td colspan="1" rowspan="1"><p data-id="c59051fb-795a-48c4-ac6e-a867fc12db38"><code>Google TSV - Multi EU [FR.MF]</code></p></td></tr><tr><td colspan="1" rowspan="1"><p data-id="84f41cbf-f7d3-42e7-9cba-c1d58cb9c253">3</p></td><td colspan="1" rowspan="1"><p data-id="9a68d7fc-302b-42d7-9ef7-addfdbdbf89d">ES</p></td><td colspan="1" rowspan="1"><p data-id="7c710992-81c4-47a6-9149-56608d5d28f0"><code>Google TSV - Multi EU [ES.MF]</code></p></td></tr></tbody></table>

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.

### 4.3 Reuse of old Content-API file datafeeds

If you already had a Content-API file datafeed (for example named `FRBE FRBEADS.xml.gz`), Multifeeds will:

1.  Locate the old data source by its stored mapping + feed label.
    
2.  Rename it to the canonical pattern:
    
    ```javascript
    {legacy name or Multifeeds feed name} [FEEDLABEL.MF]
    
    ```
    
3.  Keep the exact same scheduled-fetch URL (Multifeeds still writes the file to the same endpoint).
    
4.  If no old counterpart exists → create a new file data source using the canonical per-label pattern above.
    

* * *

## 5\. How to recognise data sources managed by Multifeeds in GMC

After migration, navigate to GMC → **Data sources** and apply these recognition rules:

### Signatures of a Multifeeds-managed data source

Rule

How to spot it

<table data-id="176408f4-dca6-44ec-a9e9-8bf6f893d48c" style="min-width: 50px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p data-id="ddc1d5a3-6e77-4fed-bfb0-ca9cb238b461"><strong>The </strong><code>[...MF]</code><strong> suffix</strong></p></td><td colspan="1" rowspan="1"><p data-id="e0e14dd5-c27b-44dd-8603-1036a6f91ea5">Every data source Multifeeds touches <strong>ends with the suffix </strong><code>[FEEDLABEL.MF]</code>. This is the app's unique watermark that identifies data sources under Multifeeds control.</p></td></tr><tr><td colspan="1" rowspan="1"><p data-id="13b301c9-bd77-42b8-90b0-f93aadbea752"><strong>"Content API" prefix</strong></p></td><td colspan="1" rowspan="1"><p data-id="328e2eb6-4e20-4848-9bcf-23e1456601df">Reused legacy API data sources start with <code>Content API [FEEDLABEL.MF]</code>.</p></td></tr><tr><td colspan="1" rowspan="1"><p data-id="a33b4d19-514f-4072-a3eb-8b83d0a0f53b"><strong>Your feed name as prefix</strong></p></td><td colspan="1" rowspan="1"><p data-id="71e3c61b-9e6f-4cd6-ab47-6c1c06635e51">Newly created data sources start with the <strong>exact feed name you typed inside Multifeeds</strong> (e.g. <code>My UK Feed [UKADS.MF]</code>).</p></td></tr><tr><td colspan="1" rowspan="1"><p data-id="3910bcee-4538-4de1-b0da-0daf4a378ffa"><strong>Type</strong></p></td><td colspan="1" rowspan="1"><p data-id="0a986552-6978-4e6a-9f9a-5c674b29cdb6">API feed → type shown as <code>API - Content API</code> (legacy GMC wording; backend is Merchant API now). File feed → type is <code>Scheduled fetch</code>.</p></td></tr></tbody></table>

### Data sources NOT owned by Multifeeds

-   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.
    

* * *

## 6\. Frequently asked questions (FAQ)

### Q1: I see 2x or 3x more data sources in GMC than before. Is this a bug?

**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.

### Q2: The old "Content API" entry was renamed to "Content API \[DE.MF\]". Does this break anything?

**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.

### Q3: Can I delete the old, non-`[...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.
    

### Q4: I still see a plain "Content API" entry (no `[...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:

1.  Trigger a full bulk sync once (Multifeeds → Feeds → "Manual refresh").
    
2.  If still not renamed, open a support ticket with: your shop origin, merchant ID, and a screenshot of the Data sources page.
    

### Q5: One of my new `[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.

### Q6: I see odd entries named "Copy of Content API" etc. Are these yours?

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.

### Q7: Can I roll back to the Content API?

**No.** Google sunset the Content API on August 18, 2026. Multifeeds no longer supports it. Rolling back would stop all feeds cold.

* * *