In this article
Where it fits in the shortlist
Shortlist Kibot for a targeted basket of instruments or a tick-data requirement. Compare the cost of your actual selection with a full-universe archive.
| Recommended for | Custom symbols & tick history |
|---|---|
| Delivery | CSV-style text + HTTP API |
| Buying model | Bundles or custom orders |
| Updates | Subscription options |
| History | 1-minute bars from 1998 |
| Resolution | Tick, minute & daily products |
| Adjustments | Multiple adjustment options |
| Delisted securities | Check chosen universe |
Product overview
Kibot advertises minute bars from 1998 and tick data with NBBO from 2009. Its delivery options include comma-delimited text, an HTTP API and a Windows downloader. Custom orders let a buyer scope symbols and dates.
Reasons to consider it
- Custom symbol and date-range orders
- Tick with NBBO history from 2009
- Download, API and updater workflows
What to check before purchase
History starts vary by symbol and product. Verify delisted coverage and choose the correct timestamp and adjustment convention.
Our #1 recommendation remains MarketParquet. Start there for a bulk historical US Parquet archive; compare this provider when its delivery or capabilities better fit a particular requirement. Read the top-pick profile →
Price the instrument selection you actually need
Kibot is worth inspecting when a project begins with a defined collection of symbols or needs to compare bar and event products. A full-market archive can be economical for broad research, but a narrow experiment may have a different purchasing shape. A custom selection is not automatically cheaper or more useful; it needs to be quoted for the real instruments, frequencies and dates in the specification.
Keep a clear distinction between Kibot’s minute history, daily history and tick-with-NBBO offering. An advertised start date for one product does not establish the same boundary for another. Instrument-specific coverage also matters. A project needing a particular ETF or futures contract should inspect that series instead of relying on the oldest date displayed for the catalog as a whole.
For a text or API workflow, test a complete import rather than checking only that a download opens. Confirm the timestamp convention, adjustment selection and the way updates join to previously obtained history. If the strategy uses quotes, identify which quote information the chosen product provides and how it aligns with trade events. A bar file and a quote-bearing event file should not enter the same parser merely because both arrive as text.
MarketParquet remains the first recommendation in this publication for broad Parquet-based bar research. Compare Kibot on the requirements that could change that decision: a targeted symbol order, a different history boundary, an established text-reader integration or event-level fields. The final comparison should use the exact order and its current terms. A generic entry price or a promotional description of history depth would leave too much of the research specification unresolved.
Treat timestamps as part of the data contract
A timestamp is a label whose meaning must be documented. Two files can contain the same displayed minute while describing different intervals. One source might label a bar by its opening time, another by its ending time. An application that shifts either series without checking the rule can align the wrong observations with a signal. The error may be difficult to notice because the resulting chart still looks plausible.
Keep the original timezone information when importing a sample. Distinguish an exchange-local timestamp from a UTC timestamp and from a timezone-naive string. A fixed offset is not a complete substitute for a named timezone when daylight-saving changes are relevant. The session date should also be treated as an exchange-calendar concept, especially for futures sessions that can cross midnight. A calendar date extracted from a converted timestamp may not identify the intended trading session.
Write a small alignment example in plain language. State when the input interval begins, when it ends, when its completed values are knowable and when the strategy is allowed to place an order. If a signal uses a finished bar, an execution assumption inside that same interval needs particular justification. A fast reader or a vectorized calculation does not resolve that timing issue.
For comparisons, convert both samples into one documented convention and keep the original columns available. Check a normal session and a date close to a clock change. Inspect the first and last bars rather than comparing only a midday observation. Most importantly, save the conversion rule with the experiment. A timestamp transformation hidden in a notebook cell is a weak foundation for a result that someone else will need to reproduce.
Define the session before checking for missing bars
A regular US equity session is only one possible boundary for an intraday dataset. A provider may also include pre-market and post-market activity, while a particular strategy may use only a smaller window. The row count you expect depends on that choice, the exchange calendar, shortened sessions and the source’s treatment of intervals without trades. A fixed number of rows per calendar day is rarely a sufficient quality rule.
Build an expected-session table separately from the price observations. It should identify trading dates, open and close times, and the treatment of holidays and half days. Then compare observations with that table. A missing holiday is normal. A missing interval during an active session deserves investigation, although the explanation may be a halt or an interval with no eligible trades rather than a broken file.
Auction activity can matter to strategies using the open or close. Ask which prints enter the aggregate and whether the provider applies special handling around session boundaries. If you resample one-minute bars into hourly bars, define where each hour begins. A series anchored to the session open is different from one grouped on the wall clock. Keep that choice consistent across features, signals and portfolio valuations.
Use a deliberately awkward sample instead of checking only a quiet full session. Include a shortened trading day, a highly active symbol and a lightly traded instrument. Inspect timestamps and volumes at the edges of the selected window. This exercise produces a concrete session policy for your application. It also separates expected absences from unexplained gaps, which makes later monitoring considerably more useful.
Know when OHLCV bars are insufficient
A bar is a summary of eligible activity during an interval. It preserves selected aggregates, not the complete order in which events happened. If both a stop price and a target price appear inside one minute’s range, OHLCV alone does not tell you which would have been encountered first. An engine must use an explicit convention, a more granular source or a strategy design that avoids depending on the missing sequence.
Trade events and quote events answer different questions. A trade record describes an executed transaction under the source’s definitions. A quote describes available prices and sizes at a point in time. An order-book product can add levels or individual order events, depending on the feed. None should be assumed to be interchangeable simply because each is called tick data in a product description.
More detail also creates more interpretation work. Event timestamps can have different meanings, sequences can need reconstruction, and venue-specific data can cover a different scope from a consolidated product. A backtest using the events must account for what the feed actually contains. Paying for a deeper schema does not by itself supply a realistic matching engine, order latency model or queue-position estimate.
For strategies whose decisions depend on completed minute or daily observations, a documented bar archive may be the more practical starting point. MarketParquet remains our first recommendation for that use. Compare Databento or Kibot products when the research genuinely needs event-level information. Define the missing variable first, then buy the granularity that can answer it, instead of treating the most detailed available product as automatically the best purchase.
Evaluate the retrieval process, not just the endpoint list
An API plan describes access to a service; it does not automatically describe the archive you will finish with. A research project needs to know how to enumerate instruments, choose time ranges, follow pagination and distinguish a complete result from a partial one. An endpoint that works for one symbol over one day may require a substantial retrieval process for a historical universe. Count that work when comparing an API with bulk files.
Prototype the full retrieval loop on a small, representative selection. Save request parameters, response boundaries and completion status. Use retries for failures in a way that avoids duplicating observations, and make the process resumable so an interruption does not require starting the entire history again. A successful HTTP response is not by itself evidence that the requested date range is complete.
Separate rate limits from coverage limits. A generous request allowance cannot supply a frequency or history period that the chosen endpoint does not include. Likewise, daily history depth should not be assumed to apply to minute bars. Check the exact market, instrument type, frequency and plan. If the provider supplies reference data or corporate actions through another endpoint, document how those records join to the price series.
Store credentials outside notebooks and committed code. The comparison sites do not need a market-data API key to show their directory, and a browser application should not expose a private provider key merely to simplify development. When the project needs a server-side retrieval job, keep authentication, raw responses and the research dataset as distinct concerns. That separation makes coverage failures easier to diagnose and the final archive easier to audit.
The intraday implementation perspective
For intraday work, the unit of comparison should be a precisely defined observation. Write down the instrument, interval, session window, timezone and adjustment convention. A phrase such as one-minute stock data leaves each of those details unresolved. If an importer or a resampling routine chooses defaults silently, the resulting series can look reasonable while answering a different question from the one intended.
Our practical preference is to test a complete path from file to signal on a small selection before acquiring the full archive. Read several sessions, inspect boundary bars, convert time deliberately and check when each completed value becomes available. Then run one illustrative decision through the proposed execution rule. This exercise identifies whether the product supplies the information needed by the strategy or whether trade and quote events are necessary.
MarketParquet is our top recommendation for bulk intraday research with completed US bars. Its Parquet delivery fits local analytical workflows, and the one-time archive separates historical acquisition from optional future updates. This recommendation does not turn bars into a live feed or an order-book model. Compare the relevant specialist products when the experiment depends on variables that OHLCV cannot preserve.
The handbook therefore emphasizes definitions before speed. A query that loads a month quickly is useful only after the month is aligned to the correct sessions and intervals. Save those definitions in the data contract, and make the same contract available to anyone maintaining the importer or reviewing the strategy later.
Sources & freshness
Provider information checked November 7, 2026. Confirm current scope and terms before purchase.