Ecommerce store data APIs: how they work and what they return

What a store data API actually returns

Every query returns store records, and the usefulness of the API depends entirely on what is in each record. An OpenData record carries 12 fields: the store's domain, its ecommerce platform, the technologies detected on the storefront, the apps detected, the payment gateways detected, the store's currency, its country, its public business email where one is published, its phone number where the store publishes one, a per-record source URL, and the date the store was last seen. 205,297 of the verified stores have a public business email (205,297 in the current snapshot) and 111,859 have a store-published business phone.

The record is the same one you get in the downloadable files, because both come from the same warehouse. Verified means OpenData fetched the store's own storefront and detected at least one ecommerce technology on it — a store that fails that check never enters the verified set. The source URL and last-seen date travel with every record, so you can audit where a row came from and how fresh it is instead of trusting a bare spreadsheet.

How filtering works

You narrow results by passing filters with each request rather than downloading a large file and sorting it yourself. OpenData's API accepts filters for platform, technology, installed app, payment gateway, country, and a has_email flag that restricts results to stores with a public business email. Filters combine: a request for Shopify stores in Germany that use a particular payment gateway returns only stores matching all three conditions.

Pagination is cursor-based, so a script can walk a large result set without duplicates or gaps. That matters when a segment holds tens of thousands of stores — you page through them in order and know exactly when you have the complete set.

• platform — Shopify, WooCommerce, Wix, Squarespace and more
• technology or app — return only stores where a specific tool was detected
• payment gateway — filter by how a store takes payment
• country — restrict to one market
• has_email — only stores with a public business email (205,297 stores)

Files vs API: which one you actually need

Most buyers do not need an API. If you are building one prospecting list, validating a market once, or loading contacts into a CRM a single time, a one-time file is cheaper and simpler: OpenData charges per row with no subscription — full records cost $4.00 per 1,000 rows, stepping down to $2.00 per 1,000 at the largest volumes — and the index is refreshed monthly, so a repeat pull stays current. You can test fit first with the free store checker (30 full-record unlocks a month) or a free sample file.

An API earns its keep when the data has to flow into a system continuously: enriching signups as they arrive, re-checking a stored list against current platform and technology data, or letting your own product query store records on demand. In those cases you are paying for the connection, not the rows — the same record costs less per row in a file, but a file cannot answer a question your application asks at 3 a.m.

Where OpenData's API lives

OpenData's API is sold through two marketplaces rather than a home-grown billing system. On RapidAPI, the Basic plan is free with 1,000 requests a month, and the Pro plan is $20 a month for 500,000 requests; API callers receive a maximum of 50 rows per request, so retrieving a large segment means paginating. On Apify, the OpenData actor charges $4 per 1,000 rows returned, which suits batch pulls where you know roughly how many records you need.

The on-site documentation describes the checker API and the endpoints behind the website itself — read the developer docs before choosing a route. If you only need to look stores up interactively, the store checker is the same data with no code at all, and the pricing page lists every file and marketplace option side by side.

• RapidAPI Basic — free, 1,000 requests/month, max 50 rows per request
• RapidAPI Pro — $20/month, 500,000 requests, max 50 rows per request
• Apify actor — $4 per 1,000 rows, suited to batch extraction

Three jobs an API is usually hired for

The first is enrichment: a user or a prospect enters a domain, and the API returns the platform, technology stack, and contact fields for that store in the same request, so your product can react immediately instead of waiting for a batch job. The second is monitoring: a scheduled job re-queries a stored list of domains and flags what changed — a platform migration, a new payment gateway, a store that no longer resolves. The third is segmentation on demand: instead of buying every slice of a database, an application pulls exactly the segment it needs — one country, one platform, stores with email — at the moment it needs it.

All three share one requirement: the answer has to be structured and current enough to act on without a human opening the file. That is what the 12-field record and the per-record last-seen date are for. If none of these jobs sounds like yours, the honest recommendation is the boring one — buy the file, use the free sample to confirm the format matches your tooling, and keep the API for the day a system, rather than a person, starts asking the questions.

What to check before you build on any store data API

Three things decide whether an API is safe to build on. First, provenance: every record should carry a source URL so you can verify it yourself. Second, the definition of the headline number — OpenData's 1,504,744 counts only stores whose storefront was fetched and matched at least one detected ecommerce technology, with one store counting as one record; a bigger number built on looser rules is not more data. Third, freshness: each record's last-seen date tells you when it was last observed, and the data behind the API is refreshed monthly rather than left to age silently.

Questions, answered straight

Next steps