Skip to main content
Unif is a commerce data API. You ask for a storefront, a product or a creator; Unif runs a cascade across its data sources in cost order, stops at the first result that verifies, and hands back a normalized record — the same field names, the same metric definitions and the same currency, whichever source answered.
Unif is in preview. The schema described here is stable enough to build against, and any breaking change ships behind a new API version. See Versioning.

​
The problem it solves

Commerce data is fragmented in three directions at once, and each one costs you separately. No single source covers everything, and the ones that cover most of it disagree about the rest.

Different shapes

One channel calls it gmv, another sales_amount, a third reports units only. Every integration needs its own parser.

Different definitions

“Revenue last 30 days” can mean orders placed, orders shipped or orders net of returns. Numbers that look comparable are not.

Different lifespans

Sources change their formats, throttle you, or disappear. Your pipeline breaks on their schedule, not yours.
Unif absorbs all three. You integrate once, against one schema; the cascade behind it is tuned, re-ordered and extended without your code noticing, and adding a channel becomes a configuration change rather than a migration.

The waterfall

Sources tried cheapest first, verified before they are returned, and charged only when one hits. This is the mechanism everything else here rests on — start there.

​
What you get back

Every response is built from six entities. They are the same six on every channel. Each record carries the period it was measured over, the currency it is denominated in, and a meta block telling you how fresh and how complete it is. Nothing is implied.

​
Channels and sources

Unif exposes channels — tiktok_shop today, more later. Behind each one is a cascade of sources, and that roster is published rather than hidden; the first TikTok Shop source is Kalodata.
Omit channel and your query spans every channel your workspace has enabled. Each returned object names its own channel, so you can still tell results apart.
What a response does not carry is which source answered that particular row. The cascade is re-tuned as sources change, and pinning your code to one of them would turn every re-tune into a breaking change. What you get instead is honesty about the result. GET /coverage reports which fields are populated for a given channel and market, how filterable they are and how far behind they typically run — so you find out before you ship a filter, not after.

​
The three things you can do

Search

Start from filters rather than identifiers. “US beauty shops above $100k that grew 25% this month” is a single search request.

Enrich

Start from rows you already have. Resolve URLs and handles into stable IDs, then pull the fields you need onto them.

Monitor

Put a set behind a tracker. Unif re-checks on a schedule and posts a signed webhook when a metric crosses your threshold.

​
Where to go next

Quickstart

From an API key to your first enriched row, in four steps.

The waterfall

The cascade, verification and early exit — the mechanism, in one page.

API reference

All 47 endpoints, with a request playground.

Credits

What each call costs and how to spend less.