Read a run's signals
Returns one page of the signals a run has already produced, newest-last, optionally from a
given time and narrowed to one or more instruments.
This is the counterpart to the real-time WebSocket channel: that channel only carries what
happens while you are connected, and only for a run that asked for relay. A run's signals
are recorded either way, so this endpoint serves them whether or not relay was ever on,
in both the sandbox and live stages — use it to catch up after a disconnect, to read a
run you never relayed, or to page back over what has already happened.
The available window moves. Signals are kept for a limited span, and the oldest are
continuously discarded as new ones arrive, so how far back you can read is not a fixed
number of hours: on a busy run it can be a good deal shorter. Every response carries
availableSinceMs, the oldest moment that can still be answered for. Asking for a
sinceMs older than that is not an error — you get everything from availableSinceMs
onwards, and that field tells you it happened.
A cursor can expire, and on a busy run it expires quickly. If the position a cursor
points at has since been discarded, the next page answers 410 rather than silently
serving a shortened page that looks complete. Treat that as a normal outcome: read
availableSinceMs from the error and start again from there.
Readable by the run's owner, and by anyone if the run is public — the same rule the
signal channel applies to a subscription.
Read a run's signals Returns one page of the signals a run has already produced, newest-last, optionally from a given time and narrowed to one or more instruments.
This is the counterpart to the real-time WebSocket channel: that channel only carries what happens while you are connected, and only for a run that asked for
relay. A run's signals are recorded either way, so this endpoint serves them whether or notrelaywas ever on, in both thesandboxandlivestages — use it to catch up after a disconnect, to read a run you never relayed, or to page back over what has already happened.The available window moves. Signals are kept for a limited span, and the oldest are continuously discarded as new ones arrive, so how far back you can read is not a fixed number of hours: on a busy run it can be a good deal shorter. Every response carries
availableSinceMs, the oldest moment that can still be answered for. Asking for asinceMsolder than that is not an error — you get everything fromavailableSinceMsonwards, and that field tells you it happened.A cursor can expire, and on a busy run it expires quickly. If the position a cursor points at has since been discarded, the next page answers
410rather than silently serving a shortened page that looks complete. Treat that as a normal outcome: readavailableSinceMsfrom the error and start again from there.Readable by the run's owner, and by anyone if the run is
public— the same rule the signal channel applies to a subscription.