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/symbolsfor 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
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.