---
title: "List signals"
method: GET
path: "/v1/signals"
tags: ["Signals"]
---

# List signals

`GET /v1/signals`

## Request

- Base URL: `https://api.trayo.ai`
- URL: `https://api.trayo.ai/v1/signals`
- Auth: HTTP bearer

**Required permissions:** `events:read`.

Returns the complete current set of your workspace's account-axis signals in a SINGLE response — every signal you have authored.

**This route does NOT paginate**, unlike `GET /v1/accounts`, `GET /v1/people`, `GET /v1/events` and `GET /v1/discoveries`. It accepts no `cursor` or `limit` (any sent are silently ignored), and the response always has `hasMore: false` and `nextCursor: null` regardless of how many signals exist. A pagination loop written against it will never advance. `POST /v1/find` is the other non-paginating route.

## Response `200`

All current signals.

- SignalListDto: The complete current set of your workspace's account-axis signals in a single response — every signal you have authored. **This route does NOT paginate**, unlike `GET /v1/accounts`, `GET /v1/people`, `GET /v1/events` and `GET /v1/discoveries`. It accepts no `cursor` or `limit` (any sent are ignored), and `hasMore` is always `false` with `nextCursor` always `null` however many signals exist. Do not write a pagination loop against it — it will never advance. `POST /v1/find` is the other non-paginating route, and it does not even return this envelope.
  - `data` object[], required: Every current account-axis signal, newest first.
    - `signalKey` string, required: The stable public identifier. There is no separate row id.
    - `type` string, nullable, required
    - `entityType` string, required
    - `detects` string, required
    - `salesIntent` string, nullable, required
    - `includes` string[], required
    - `excludes` string[], required
    - `weight` number, required
    - `createdAt` string, date-time, required
    - `updatedAt` string, date-time, required
  - `hasMore` false, required: ALWAYS `false`. This route does not paginate.
  - `nextCursor` unknown, required

## Other responses

- `401`: Missing, malformed, or incorrect bearer token. Every way authentication can fail returns the identical body, so do not try to infer which one it was, and do not repeat the call with the same key. `unauthorized` (`retry: do_not_retry`) — Missing, malformed, or incorrect bearer token. Identical body for every cause.
- `403`: The key grant and its owner's current workspace role must both include every scope required by the operation. `insufficient_scope` (`retry: do_not_retry`) — Scope denial details distinguish missing_key_scope (use a key granting every missing scope), owner_permission_limit (the owner needs the missing workspace permissions), and invalid_key_scope (replace the key with supported scopes). Membership and undeclared-route denials remain generic.
- `429`: Every route is rate limited per workspace across REST, MCP, all keys and OAuth users, `GET /v1/whoami` included, so a balance poll competes with the work it is watching. For `rate_limited`, wait `Retry-After` seconds (also `details.retryAfterSeconds`), then send the same request once; do not retry sooner. `RateLimit-Limit`, `RateLimit-Remaining` and `RateLimit-Reset` describe the workspace's bucket, and they come back on successful responses too: read them and slow down BEFORE you are refused. A burst from one network can also be refused before the key is checked; that 429 carries `Retry-After` and no `RateLimit-*` headers. `rate_limited` (`retry: retry_later`) — The workspace or source network exhausted its request budget for one bucket. `details.retryAfterSeconds` (and `Retry-After` on REST) is the wait: wait that long, then retry the same request once. Do not poll or retry sooner; an early retry is refused again. If you cannot wait, stop and tell the user when to retry; do not fill the wait with other calls. `details.limit` and `details.bucket` name the exhausted budget. When present, RateLimit-* headers describe the active budget and reset.
- `500`: Something failed on our side. Nothing about the request needs changing. `internal_error` (`retry: retry_later`) — Something failed on our side. `message` never describes it — quote `requestId` when reporting. Retry with exponential backoff and GIVE UP after a few attempts: `retry_later` here does not mean the failure is known to be transient, only that nothing about your request needs changing. A request that fails this way repeatedly will not start working.

---

[API](https://skmtc.dev/trayo/apis/trayo-api.md) · [All operations](https://skmtc.dev/trayo/apis/trayo-api/llms.txt) · [OpenAPI document](https://skmtc.dev/trayo/apis/trayo-api/revisions/0af452dce6de?raw)