Skip to main content

Outcome

Make one market- and data-type-specific coverage decision before writing reusable code or widening a data job. Start with Venues and market types for the source hierarchy. This guide checks coverage for one selected market and data type.

Prerequisites

  • Preserve one symbol or market identity exactly as supplied by the product or venue.
  • Choose one data type and one bounded UTC window.
  • Use /v1/symbols for public discovery when the venue, market type, or identity is not known.
  • Load an API key for the selected authenticated market-data and quality calls.

Inputs

Steps

1

Discover the symbol

Find the row whose exchange and symbol match the requested market. Preserve the exact spelling, pair separator, builder prefix, outcome identity, and generated slug when present.
2

Read schema-specific coverage

Inspect the row’s coverage_by_type for the selected data type. A top-level coverage start or a coarse summary does not establish the date for every schema.
3

Call the exact delivery route

For the example inputs:
4

Attach the quality decision

Check the same venue, market type, symbol, data type, and window with the relevant data-quality route before using the response in a downstream job.

Expected state

The API namespace, market, data type, and window agree. The response is interpreted through the selected market type, not through a visually similar ticker in another namespace. An empty response is still a result to classify, not permission to substitute another symbol. Lighter L3 is individual-order depth, not an aggregated L2 shape. /v1/lighter/l3orderbook/{symbol} returns numeric order_index, owner_account_index, price, remaining_size, and original_size; the two index fields are Lighter indexes, not wallet addresses or raw order IDs.

Verification

Confirm the selected API namespace against Venues and market types. Use /v1/status/coverage only for a coarse public summary. Use /v1/symbols coverage_by_type or /v1/data-quality/coverage/{exchange}/{symbol} for a selected symbol and schema window. The exact endpoint/account/key contract is separate from coverage. Inspect the endpoint and verify the account/key response before relying on a result.

Failure and recovery

  • No matching symbol row: stop and keep the supplied identity unchanged.
  • A schema is absent from coverage_by_type: do not infer it from an adjacent data type.
  • 400: fix the named symbol, parameter, or time window.
  • 401: repair the key source or header.
  • 403: inspect the exact endpoint/account/key response; do not turn the status into a general market-availability claim.
  • 404: return to the route root and check the namespace before retrying.
  • A coverage or incident failure: narrow, delay, mark, or stop the downstream job.

Saved run metadata

The zero UUID is a shape placeholder only. Replace it with the UUID returned by the route or client wrapper.

Next task

Open Choose venue and market type for namespace selection, then use the matching page under REST API for the next bounded call.
Last modified on September 3, 2026