Parts Compatibility Data Feeds vs. APIs

There are two ways a platform can get compatibility data into its system: ask for it when it needs it, or receive the whole thing in a file and load it in on a schedule. The first is an API. The second is a feed. Most integration questions people actually mean to ask are really "which one of these do I need" — and the honest answer is that it depends entirely on what's on the other end.

Why marketplaces default to feeds

Marketplaces that support fitment-based listings — auto parts categories on eBay Motors, Amazon, and fitment integrations tied to Google Shopping — generally process compatibility data as a batch operation on their own schedule. They're matching millions of listings against a vehicle database at their own cadence, not making a live call out to your system every time a shopper searches. That means they want the data delivered as a file, in their specific expected format, not queried live.

This is a platform constraint, not a data quality choice. The underlying compatibility data can be exactly as accurate either way — the feed format is just what that particular door accepts.

Why your own product pages usually want an API instead

If you control the platform — your own website, your own catalog system — a live API call is almost always the better fit. A part gets enriched once, and every page that references it reflects the current state automatically. There's no export schedule to manage, no file to regenerate, and no window where the live data and the last-exported file have quietly drifted apart.

The staleness problem feeds always carry

A feed is a snapshot. It's accurate at the moment it's generated and then it's frozen until the next run. If a part number gets superseded, or a fitment record gets corrected, the day after your last export, every system consuming that feed keeps serving the outdated version until the next scheduled refresh — which, depending on how often the feed runs, can be hours or weeks.

This isn't a reason to avoid feeds where they're genuinely required. It's a reason to know exactly which pieces of your stack are running on a snapshot and which are running live, so a correction you make today doesn't quietly fail to reach a platform that's still working off last month's file.

How PartWiz handles both

The core PartWiz output is a live REST API — send a part number, get back the current, verified record. For platforms that specifically require a bulk feed format, that same enriched data can be exported as one, so you're not maintaining two separate, potentially conflicting sources of truth for the same catalog.