read is the situation report. One call assembles the current picture for an
asset across every domain that applies to its plane, so your agent does not
stitch together price, funding, technicals, and the rest by hand. This
is the call an agent makes first, and often the only one it needs. It works on
both planes: a crypto asset returns a market assessment and a headline; an
equity returns a headline.
Parameters
One canonical asset ID. Mutually exclusive with
ids.Two to ten distinct canonical asset IDs, comma-separated. Mutually exclusive
with
id.id or ids, never both. read is the only situation
operation and takes no other parameters. Nothing to tune, nothing to get
wrong.
Billing
One credit per distinct returned asset. A singleid costs one credit. A
batch reserves up to ten and settles the actual number delivered, so
ids=crypto:bitcoin,crypto:ethereum costs two credits when both are returned.
An asset that is refused rather than returned is not charged.
Response
The envelope is a single{"data": ...} object. Each asset carries a
headline, an assessment (crypto only), and, when anything cannot be
served, an unavailable block. Freshness clocks (as_of, status,
next_update_at) travel with the data, and measured values arrive with
their own percentile against the stated baseline, so every number lands
already ranked against its own history. A trimmed crypto example:
assessment states are rule-derived and each names the rule version
that produced it. A component that cannot be delivered is listed under
unavailable with a typed reason rather than filled with a placeholder. The
contextual shape {"value": ..., "pctl": ...} appears on measurements that
carry a percentile; where a value is a plain number it is returned directly.