---
title: "What Is an API Feed? How Product Data Feeds Work"
description: "What is an API feed? A connection that sends single product records between systems on request. How it differs from a file feed and where it fails."
canonical: "https://www.productmetrics.io/blog/what-is-an-api-feed"
pageType: article
language: en
publisher: "Product Metrics"
author: "Berend Vrakking"
datePublished: 2026-11-07
dateModified: 2026-11-07
image: "https://www.productmetrics.io/og/blog/what-is-an-api-feed.png"
---

> Content index: https://www.productmetrics.io/llms.txt

# What Is an API Feed? How Product Data Feeds Work

## Key takeaways

- An API feed moves single product records on request or on change; a file feed replaces the whole product list on a daily, weekly or monthly schedule.
- With a daily file fetch, Google works with an old price for half a day on average after you change it, and a full day at worst.
- A 200 response means Google stored your input, not that the product can serve. Read the processed product's status before you call an update live.

An API feed is a connection through which one system requests current product records from another, or pushes changes to it, one record at a time instead of in a scheduled file.

The gap it closes is time. I worked out that a daily file fetch leaves a price change unseen by Google for 12 hours on average, using Google's own fetch schedules and assuming changes land evenly through the day.

An API feed shortens that wait, but only if you check what Google did with the update.

## What is an API feed?

An API feed is a product data feed delivered through an application programming interface (API): software asks for specific records, or sends them, through agreed endpoints.

If a file feed is a printed price list, an API feed is a phone line to the stockroom.

The [National Institute of Standards and Technology's API definition](https://csrc.nist.gov/glossary/term/Application_Programming_Interface) calls an API a system access point with well-defined syntax that application programs can use. In practice, both systems agree on four things:

| Part | What it defines | Jacket example |
|---|---|---|
| Endpoint | The address for a resource | `/products/JKT-042-M` |
| Method | The operation the caller wants | Read the record |
| Authentication | How the caller proves access | A token in the request header |
| Response format | How results and errors come back | JSON with a status code |

The record itself holds structured fields such as SKU, price, availability and stock.

### Can an API feed change data, or only read it?

An API feed can do either, depending on the permissions it grants. An advertising platform might only read your products, while a connected app might also write an update back to the source.

Permission to read never implies permission to write, so check both before you connect anything.

## Data feed vs API feed: what's the difference?

A data feed (file feed) delivers a full snapshot on a schedule; an API feed moves individual records when they are requested or changed.

The choice decides how fresh your prices are and how much engineering you take on.

| Criterion | File feed | API feed |
|---|---|---|
| Delivery | Scheduled download over HTTP, HTTPS, FTP or SFTP | Requests or pushes through defined endpoints |
| Freshness | Daily, weekly or monthly | Can follow each change, subject to processing |
| Update size | The whole file every run | One record, field or batch |
| Format | CSV, TSV or XML file | JSON or XML with status codes |
| Errors | Checked per file or row after processing | Returned per request or field |
| Access | Protected file location | Tokens or keys with set permissions |
| Effort | Low: export, schedule, check | Higher: rate limits, retries, pagination |
| Best fit | Few products, infrequent changes | Fast-changing prices or stock, write-back |

### How stale can a file feed get?

A file feed can be up to one full interval out of date, because a change made just after a fetch waits for the next one.

[Google Merchant Center](https://www.productmetrics.io/glossary/google-merchant-center "Google Merchant Center (GMC) is a free Google tool where a shop uploads and manages its product data, so its products can appear on Google Shopping and across Google.") fetches a file feed daily, weekly or monthly at a set hour, as Google's [scheduled data-feed documentation](https://developers.google.com/shopping-content/reference/rest/v2.1/datafeeds) lists.

**Figure: Hours before a price change reaches Google, by update method.** A daily fetch averages 12 hours of stale prices and a weekly one 84. An hourly API poll cuts the average to 30 minutes.

![Bar chart of hours before a price change reaches Google: weekly file fetch 84 average and 168 worst case, daily fetch 12 and 24, hourly API poll 0.5 and 1.](https://www.productmetrics.io/images/blog/what-is-an-api-feed/api-feed-freshness-lag.webp)

| Hours, by update method | Average wait | Worst case |
| --- | --- | --- |
| Weekly file fetch | 84 | 168 |
| Daily file fetch | 12 | 24 |
| API poll every hour | 1 | 1 |

_Source: Calculated from Google's scheduled fetch options (daily, weekly or monthly at a set hour): worst case is the full interval, average is half of it, assuming changes are spread evenly. Excludes Google's processing time. Hourly poll is an example connector setting._

A monthly fetch can be up to a month behind. An API poll or push removes most of that wait, but your store still has to detect the change, the connector has to send it and Google has to process it.

A neglected API job leaves prices as stale as a neglected export.

Format is a separate decision from delivery. CSV is easy to inspect in a spreadsheet, while JSON handles nested structures such as variants; Scrappey's guide helps you [compare CSV and JSON formats](https://scrappey.com/blog/csv-vs-json-a-quick-web-scraping-guide-csv-vs-json-in-practice) before you settle on one.

## How does an API feed work?

An API feed works as a short exchange between a client, the software asking, and a server, the software answering. The client is usually a connector, not a person in a browser.

**What happens when a connector asks for one product**

1. **Build the request.** The client, here your connector, calls the product endpoint with a stable product ID, so the server returns one record instead of the whole export.
2. **Prove it may ask.** The request carries a credential, usually a token in a header. The server checks identity and permission before it reads anything.
3. **Validate and answer.** The server checks the request and returns a status code with a JSON or XML body. A 400 means a bad request, not a missing product.
4. **Read the fields that matter.** The client takes price, currency, availability and an update timestamp. A price without its currency is unusable.
5. **Store, retry or escalate.** A valid result is stored. Temporary failures are retried with growing pauses; invalid payloads and permission errors go to a person.

Many product APIs, including Google's Merchant API, follow REST, the architectural style that Roy Fielding introduced in his 2000 doctoral dissertation at the University of California, Irvine, as this [IEEE Computer article on REST](https://www.computer.org/csdl/magazine/co/2015/06/mco2015060007/13rRUx0xPA5) describes.

REST identifies each resource by a URL and keeps requests stateless: every request carries everything needed to process it.

REST doesn't define what a record means. The API's documentation has to settle identifiers, units, currency, timestamps and which kind of message each call sends:

| Message type | Contains | Risk if misread |
|---|---|---|
| Full snapshot | Every product and field | Absent products read as deleted |
| Delta | Only what changed | Read as a snapshot, it wipes unsent fields |
| Delete event | The ID of a withdrawn product | Missed, the product stays live |

### What keeps an API feed reliable?

Four controls keep an API feed from failing quietly or creating duplicates:

| Control | What it does | What it prevents |
|---|---|---|
| Exponential backoff | Waits longer before each retry | Hammering a struggling server |
| Idempotent writes | Makes a repeated write safe | Duplicate products after a retry |
| Pagination | Reads large lists page by page | Timeouts on big product sets |
| Conditional requests | Uses `ETag` or `Last-Modified` | Re-sending unchanged records |

Caching needs a deliberate setting per field, because a cached price is a stale price:

| Data | Cache lifetime |
|---|---|
| Descriptions and images | Hours |
| Price | Minutes, or none |
| Stock | Minutes, or none |
| Authenticated responses | Never in a shared cache |

Choose the simplest method that meets your freshness and recovery needs. A well-run file feed beats a neglected API.

## Why doesn't a successful API call mean a live product?

A successful API call means Google stored what you sent, not that the product can appear in ads.

Google's [Merchant API product overview](https://developers.google.com/merchant/api/guides/products/overview) separates `ProductInput`, the raw data you submit, from `Product`, the read-only result after feed rules, supplemental data and validation, including its final status and issues.

Say a retailer sends Google Shopping a lower jacket price through the Merchant API, which replaced Content API for Shopping in 2026.

The request returns 200, the merchandiser sees the new price in the store, and the marketer assumes the ad is updated.

![Merchant API example: a jacket's ProductInput with a new price but no image link returns 200 OK, then the processed Product shows a missing image link and a disapproval.](https://www.productmetrics.io/images/blog/what-is-an-api-feed/api-feed-submitted-vs-processed.webp)

_The request succeeded and the price arrived, yet the processed product can't serve in Shopping ads._

The Merchant API writes through insert, patch and delete on `ProductInput`, and reads through get and list on `Product`.

A connector can patch one attribute rather than resend the whole product set, but it should always read the processed product back. Our [Merchant API guide](https://www.productmetrics.io/blog/google-shopping-apis) covers authentication and the daily call quota that read-back uses.

### Polling or webhooks: which keeps a feed fresher?

Webhooks keep a feed fresher because the source announces each change, while polling only finds changes at the next check. Polling is simpler to run and recover:

| | Polling | Webhooks |
|---|---|---|
| How updates arrive | Receiver asks at intervals | Source notifies on change |
| Freshness | Stale between checks | Close to real time |
| Wasted requests | Many, for unchanged records | Few |
| What you must build | Interval and retry logic | Callback authentication, duplicate and out-of-order handling, downtime recovery |

Neither removes reconciliation. A missed webhook leaves a gap only a scheduled comparison of source and destination will find.

### Where do API feeds go wrong?

API feed failures usually show up as a mismatch between your store and Google Shopping. Diagnose the symptom before changing the architecture:

| Symptom | Likely cause | Fix |
|---|---|---|
| Shopping prices lag the website | Interval too long or a missed run | Shorten the interval or push on change |
| Rejected after a successful call | Missing required attribute | Validate before sending; read field errors |
| Duplicate products | Unstable IDs or non-idempotent retries | Stable product IDs, idempotent writes |
| Sold-out items still advertised | Stock cached too long | Shorter stock cache, scheduled reconciliation |
| Rate-limit errors | Too many requests at once | Back off, paginate, batch updates |

Track freshness lag where the record becomes usable, not when your connector sent it, along with rejected records, duplicates and recovery time.

Give every alert a named owner; for rejections, our list of [Merchant Center errors](https://www.productmetrics.io/blog/google-merchant-center-errors) gives the fix for each.

> **Get more revenue out of Google Shopping.** Every product segmented and labelled in Merchant Center, so your top performers get more priority. [Analyse your products for free](https://app.productmetrics.io/) Log in with Google, no credit card.

A correct feed lets Google show the right product. It doesn't tell you which products deserve more priority.

At Product Metrics, we read your Google Ads and Merchant Center data and write only the labels you approve: [Product Segmentation](https://www.productmetrics.io/product-segmentation) sends each product's segment to Merchant Center as a custom label through a [supplemental feed](https://www.productmetrics.io/glossary/supplemental-feed "A Google Merchant Center supplemental feed is a secondary data source that adds details to, or overrides details in, the products of your primary feed."). We never change your prices.

## Which product fields should an API feed share?

An API feed should share only the fields and operations the recipient needs, a principle called least privilege. A product record often sits next to cost price, margin, exact stock and unpublished prices that Google never needs.

[Akamai's 2026 API Security Study](https://www.akamai.com/site/en/documents/analyst-report/2026/api-security-study-2026.pdf), a survey of 1,840 security professionals published in April 2026, found that 87% of organisations had an API-related security incident in the previous year, and fewer than one in four knew which of their APIs return sensitive data.

| Field | Send to Merchant Center? | Why |
|---|---|---|
| Title, price, availability, link | Yes | Required to show the product |
| [Custom labels](https://www.productmetrics.io/glossary/custom-labels "Custom labels are five attributes in a product feed, custom_label_0 to custom_label_4, that you fill with your own text to group products in campaigns.") | Yes | Group products for campaigns |
| Cost price and margin | No | Internal; never needed by Google |
| Unpublished future prices | No | Could go live too early |
| Customer data | Never | Not product data |

Set field-level permissions where the API supports them, rotate tokens and keep test and production apart. Audit logs should record who read or changed which record, without storing the sensitive payloads themselves.

### How do you protect the feed itself?

Protect the feed by authenticating every webhook, rejecting replayed messages and rate-limiting without blocking legitimate recovery traffic. [Akamai's 2026 application and API security report](https://www.akamai.com/site/en/documents/state-of-the-internet/2026/app-api-ddos-security-report-2026.pdf) counted 258 daily API attacks per enterprise in 2025, up 113% from 121 in 2024.

**Figure: Average daily API attacks per enterprise.** Daily API attacks per enterprise more than doubled in a year, from 121 to 258.

![Bar chart of average daily API attacks per enterprise from Akamai's 2026 report: 121 in 2024 rising to 258 in 2025, an increase of 113%.](https://www.productmetrics.io/images/blog/what-is-an-api-feed/api-daily-attacks.webp)

| Year | Daily API attacks |
| --- | --- |
| 2024 | 121 |
| 2025 | 258 |

_Source: Akamai, Apps, APIs, and DDoS State of the Internet report, March 2026_

Then ask each feed provider five questions:

| Question | A good answer |
|---|---|
| Which fields leave the source? | A field list you can restrict |
| How long are records and logs kept? | A stated retention period |
| What triggers a refresh? | A change event or a fixed interval |
| Where do rejected records appear? | A report with field-level errors |
| How do you compare source and processed values? | An export you can reconcile |

A provider that can't answer the last question can't prove its feed is accurate. Our guide to [Merchant Center feed rules](https://www.productmetrics.io/blog/merchant-center-feed-rules) shows where source values can change on the way in.

## Should your store use an API feed?

Use an API feed when prices or stock change between scheduled fetches, or when a recipient needs single-record updates or write-back. If a daily snapshot is fresh enough, a file feed is easier to run.

| Signal | Favours a file feed | Favours an API feed |
|---|---|---|
| Price and stock changes | Weekly or less | Several times a day |
| What the recipient needs | A complete snapshot | Individual changes |
| Write-back | None | Updates flow back to the source |
| Engineering time | Little to spare | A team owns retries and monitoring |

Two signals in the right-hand column usually settle it. For the file route, our guide to [Google product feeds](https://www.productmetrics.io/blog/google-product-feeds) covers ID mapping and fetch schedules.

### How do you test an API feed before trusting it?

Test an API feed by tracing a handful of SKUs from source value to processed destination product.

Map each source field to its destination and document transformations such as availability values, currency and variant IDs, so developers and merchandisers check the same results.

Set a freshness target in minutes or hours that matches the cost of a stale price, then run four test records through it:

| Test record | What it proves |
|---|---|
| Price change | Updates arrive within your target |
| Withdrawn product | Deletes reach the destination |
| Invalid record | Errors surface and reach an owner |
| Resent unchanged product | Retries don't create duplicates |

Setting up Product Metrics means connecting Google Ads and Merchant Center, choosing [ROAS](https://www.productmetrics.io/glossary/roas "Return on ad spend (ROAS) is the revenue your ads generate for every euro you spend on them.") or [POAS](https://www.productmetrics.io/glossary/poas "POAS (profit on ad spend) means contribution profit before advertising divided by ad spend: the profit each euro of ads leaves.") and adding the supplemental feed once; it doesn't replace these checks on the records underneath.

## Final thoughts

The green "connected" light is the least useful signal an API feed gives you. What counts is the processed product: the right price, an approved status, within a time you set.

Approve an integration when your team can show those three on real SKUs, including the broken ones.

When the feed spans a commerce platform, a warehouse system and a supplier network, Continuum Solutions' [system integration support for enterprise teams](https://continuumsolutions.com.au/custom-integrations/) is one way to settle who owns each connection.

If you run a dropshipping store, supplier choice comes before feed design, because the supplier's own stock data is what your feed passes on. A guide to [find suppliers for Shopify jewelry dropshipping](https://www.jewelrybuydirect.com/blog/shopify-jewelry-dropshipping?articleId=620407226454) covers the sourcing side.

## Frequently asked questions

### Do I need a developer to set up an API feed?

Not always. Google sales-channel apps for ecommerce platforms sync products to Merchant Center through the API for you. A custom connector between your own systems and the Merchant API needs a developer to build and maintain it.

### Can a file feed and an API feed work together?

Yes. Merchant Center combines one primary data source with supplemental sources matched on product ID. A scheduled file can carry the full product data while another source updates specific fields, such as custom labels.

### Is an API feed more secure than a file feed?

Not by default. An API feed can limit access per token and per field, but only if those permissions are set up. A file at a protected URL with tight credentials can be safer than an API token that reads every field.

## Keep reading.

- [Google Shopping feed setup: requirements, refresh and fixes](https://www.productmetrics.io/blog/feed-google-shopping)
- [Profit In Practice End-To-End COGS And Margin Integration For Google Shopping](https://www.productmetrics.io/blog/cogs-margin-google-shopping)
- [The Google Shopping Segmentation Playbook For 2026 Frameworks Labels And Structures](https://www.productmetrics.io/blog/google-shopping-segmentation-playbook)

---

Written by Berend Vrakking, founder of Product Metrics. Last updated 2026-11-07.

1M+ products analysed · Nominated at the Dutch Search Awards for Best Measurement Campaign (2023) and Best Use of Data (2024)

HTML version: https://www.productmetrics.io/blog/what-is-an-api-feed