Definition and how it works
A Market Data API is a software interface that delivers market-related information (for example, quotes, trades, or bars) from one or more data sources to your application. Before evaluating vendors, separate stable mechanics (how the API represents and transports data) from variable conditions (how the underlying market behaves, what the provider chooses to publish, and how often updates arrive). This helps you avoid confusing “the API delivered something” with “the data is adequate for your purpose.”
Typical request/response flows include authentication, selecting an endpoint, choosing instrument identifiers, specifying a time range or subscription, and receiving payloads that contain fields plus metadata (often timestamps and status indicators). Assume time handling matters: the same event can appear at different times depending on provider clocks, ingestion delays, and how timestamps are defined.
Evidence checklist: what to verify
Use a due-diligence checklist and collect evidence you can review in writing.
- Data coverage and identifiers
- Which instruments are available (and how they are identified)? Use the provider’s documentation to confirm mappings and supported formats.
- Are all required field types present for your use case (for example, bid/ask, last trade, volume, OHLC bars, corporate-action adjusted series)?
- Field definitions and normalization
- Confirm precise definitions for each field. For example, define what “last” means in the provider’s feed and whether bars are based on trades or quotes.
- Check how the provider normalizes symbols, decimals, currency codes, and units.
- Timestamps, time zones, and ordering
- Verify what each timestamp represents (event time vs. processing time) and the time zone standard used.
- Test ordering: do updates arrive out of order during load, and how does the API signal that?
- Update frequency and delivery mode
- Determine whether the API is polling (request/response) or streaming (subscription). These behave differently under network variability.
- Validate the expected update cadence and the practical behavior under load, using your own test logs.
- Reliability and failure modes At least one material failure mode should be identified and tested:
- Missing data or gaps during outages.
- Retries that duplicate events.
- Rate limiting leading to partial coverage.
- Error responses that do not preserve request context.
- Rate limits, quotas, and cost drivers Even without live pricing claims, you can verify the cost drivers:
- Rate limits per key and whether there are separate limits for different endpoints.
- Payload size (number of instruments per request, bar granularity) and bandwidth impact.
- Any licensing or usage constraints that limit redistribution or storage.
- Historical backfill and reproducibility If you need historical series, verify whether you can reproduce the same dataset later:
- Is backfill supported for a time range?
- Are data revisions possible, and if so, how are updated values communicated?
- Security and data integrity checks
- Confirm authentication method requirements (without assuming they are sufficient for your environment).
- Validate integrity signals in responses (for example, checksums or status flags, if provided) and log all response metadata.
Limitations, risks, and the “red flag” mindset
Market data quality issues often come from mismatches between what you assume and what the provider publishes.
- Time inconsistency: Historical or real-time timestamps may not align with your system clocks, leading to incorrect sequencing or windowing.
- Provider feed interpretation: Field semantics can differ across sources (for example, how bars are constructed). Historical relationships can fail because future market behavior changes and because the feed may reflect different event types over time.
- Operational risk: Rate limits, network jitter, or service interruptions can create gaps, duplicates, or delayed updates. These can distort downstream calculations if you treat data arrival as the same as event occurrence.
- Verification gap: Documentation alone is not evidence for your environment. Run controlled tests: compare sample outputs against an independent reference when possible, and record discrepancies.
One important klaarcriterium is that you can explain your data pipeline using explicit assumptions: what time definition you use, how you handle missing values, how you deduplicate, and what you do when rate limits trigger.
Verification and next questions to ask
To evaluate independently, choose a small set of representative instruments and time windows, then verify these points in your own logs:
- Do timestamps meet your sequencing requirements? - Are there observable gaps, duplicates, or error bursts under realistic request volume?