---
title: "read: signals"
description: "a monitor, a subject, a kind or a strategy, and a window to the facts, with the coverage and the count not evaluable for the same window"
section: reference
address: /reference/read/signals
contract: 0476e35e6e275db5
---
# read: signals
a monitor, a subject, a kind or a strategy, and a window to the facts, with the coverage and the count not evaluable for the same window
[figure: The caller sends SignalsInput to /v1/read/signals. The platform returns a card whose body is SignalsAnswer.]
POST/v1/read/signals
Read matches. Read signals. The call needs the strategy rung under a token with the read grant, and it is served by either, by the size bound.
The route takes [SignalsInput](/concepts/signalsinput) and returns a card whose body is [SignalsAnswer](/concepts/signalsanswer).
## Request body
The request body is [SignalsInput](/concepts/signalsinput).
| field | type | required | note |
|---|---|---|---|
| `monitor` | `id` | no | |
| `subject` | `id` | no | |
| `kind` | [KindOfSignal](/concepts/kindofsignal) | no | |
| `strategy` | `id` | no | |
| `window` | [Window](/concepts/window) | yes | |
| `catches` | `bool` | no | read catches instead |
## Response
The route returns a card whose body is [SignalsAnswer](/concepts/signalsanswer). Every card ends with a foot that states the basis of each number, the scope of the call, and the time when the facts were true.
## Headers
| header | required | meaning |
|---|---|---|
| `Scale-Scope` | yes | the scope the call runs in: tenant/, then /brand/, then /strategy/ |
| `Scale-As-True-On` | no | the date the facts must have been true on; defaults to now |
| `Scale-As-Known-On` | no | the date the facts must have been known on; defaults to now |
| `Scale-Key` | no | for a change, the key made from the input; a repeat under the same key returns the unit held and writes nothing |
A caller needs the strategy rung and a token with the read grant. The platform or the desktop app serves this route.
## Example
The example sends the smallest body that SignalsInput allows. The build validates it against the schema of SignalsInput.
Example
```sh
curl -X POST https://api.scaleintelligence.co/v1/read/signals \
-H "Scale-Key: $SCALE_KEY" -H "Scale-Scope: tenant/" \
-H "content-type: application/json" \
-d '{ "window": { "from": "…", "to": "…" } }'
```
```typescript
import { client } from "@scale/sdk";
const answer = await client.read.signals({
"window": {
"from": "…",
"to": "…"
}
});
// answer.body is a SignalsAnswer. answer.foot holds the basis, the scope and the time.
```
```python
import requests
answer = requests.post("https://api.scaleintelligence.co/v1/read/signals",
headers={"Scale-Key": KEY, "Scale-Scope": "tenant/"},
json={
"window": {
"from": "…",
"to": "…"
}
}).json()
```
```rust
let answer: Card = client.post("https://api.scaleintelligence.co/v1/read/signals")
.header("Scale-Key", key).header("Scale-Scope", "tenant/")
.json(&SignalsInput { /* the fields of the page */ }).send().await?.json().await?;
```