Lixinger Universal Financial Data Query

Problem

Querying Lixinger financial data is not mainly blocked by missing endpoints; it is blocked by endpoint mapping and format discipline. A phrase such as “valuation percentile,” “financial statements,” or “northbound funds” must be routed to a specific POST API, while stock-code normalization, stockCode vs stockCodes, metric IDs like y.ps.toi.t, sector-specific endpoints, and percentage conversion are easy to get wrong. Calling the APIs directly also requires handling authentication, rate limits, retries, and presentation rules.

How It Works

lixinger-universal wraps 50+ Lixinger open-platform endpoints as a natural-language query layer for engineers. It maps keywords to endpoints such as fundamental, fs, candlestick, dividend, and mutual_market; standardizes stock codes; selects single or array parameters; and converts decimal ratios to percentages and yuan amounts to hundreds of millions. The Token is read from ~/.workbuddy/skills/lixinger-universal/config.json instead of being embedded in code or printed in chat. Execution goes through scripts/lixinger_universal.py, which handles 429 throttling, timeout retries, and pretty JSON output.

Boundaries

Use it for data already exposed by Lixinger, including company basics, shareholding changes, trading records, operating data, shareholders, dividends, valuation, financial statements, heat indicators, and capital flows. It does not invent missing data. Banks, securities firms, and insurers require endpoints such as fundamental_bank, fs_security, and fs_insurance; market_cap is not returned by fundamental and should be fetched from company. The data is for analysis reference and is not investment advice.