Create a dataset by importing history instead of uploading it
A second way to get data into a dataset, alongside POST /datasets: instead of PUTting a
file yourself, ask the API to go fetch history on your behalf. Creates the dataset and
starts the fetch in the same call — there is no separate upload step, and the result lands
as a dataset version indistinguishable from an uploaded one once it's ready. Poll
GET /datasets/{datasetId}/imports/{importId} for progress.
type selects the kind of venue the history comes from, with the same two values as the
venueType of GET /exchanges: dex — history over a pool/pair's own on-chain market —
and cex — the history of a centralized exchange's market, kept by the platform. Each
has its own block (dex, cex). The exchange id of a cex import has to be a centralized
exchange of GET /exchanges; a decentralized one (robinhood, say) is 400, and is imported
with type: dex.
A cex import covers one instrument over a range: the API reads that range of the
exchange's history, builds the bars of the requested cadence from the finest data it has
for it, and stores the result as a dataset version, exactly as for an upload. cex.dataType
picks tickers or klines and is also the resulting dataset's type. The range is capped by
your tier like any import (maxImportRangeHours of GET /account).
A dex import has two data shapes, chosen by the top-level cadence:
Omitted/blank (default) — on-chain swap history, replayed directly from the pool/pair's
own chain. Cadence is native, not resampled: each swap keeps the timestamp it happened
at rather than being bucketed into candles, so the resulting version's cadence is rt
unless the swaps happen to sit on a fixed grid (see DatasetVersion.cadence).
One of 1s / 1m / 5m — pre-aggregated candles at that width instead of raw trades.
The resulting dataset's type is klines, not ticker. Not every network supports every
cadence yet — an unsupported combination fails asynchronously, same as an unresolvable
pool (see the failed status on the poll endpoint below).
Create a dataset by importing history instead of uploading it A second way to get data into a dataset, alongside
POST /datasets: instead ofPUTting a file yourself, ask the API to go fetch history on your behalf. Creates the dataset and starts the fetch in the same call — there is no separate upload step, and the result lands as a dataset version indistinguishable from an uploaded one once it's ready. PollGET /datasets/{datasetId}/imports/{importId}for progress.typeselects the kind of venue the history comes from, with the same two values as thevenueTypeofGET /exchanges:dex— history over a pool/pair's own on-chain market — andcex— the history of a centralized exchange's market, kept by the platform. Each has its own block (dex,cex). The exchange id of aceximport has to be a centralized exchange ofGET /exchanges; a decentralized one (robinhood, say) is400, and is imported withtype: dex.A
ceximport covers one instrument over a range: the API reads that range of the exchange's history, builds the bars of the requestedcadencefrom the finest data it has for it, and stores the result as a dataset version, exactly as for an upload.cex.dataTypepicks tickers or klines and is also the resulting dataset'stype. The range is capped by your tier like any import (maxImportRangeHoursofGET /account).A
deximport has two data shapes, chosen by the top-levelcadence:cadenceisrtunless the swaps happen to sit on a fixed grid (seeDatasetVersion.cadence).1s/1m/5m— pre-aggregated candles at that width instead of raw trades. The resulting dataset'stypeisklines, notticker. Not every network supports every cadence yet — an unsupported combination fails asynchronously, same as an unresolvable pool (see thefailedstatus on the poll endpoint below).