Query Signal Detections

Signal detection endpoints expose published signal detections for the authenticated workspace. This includes detections produced by keyword runs and any manually added detections. All items are workspace-scoped.

Request body

Results are sorted by detection date descending (most recent first).

Example request

curl -X POST "https://api.getsillage.com/api/v2/workspace/signals/query" \
  -H "Authorization: Bearer $SILLAGE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"limit":25}'

const response = await fetch('https://api.getsillage.com/api/v2/workspace/signals/query', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.SILLAGE_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ limit: 25 }),
})

const result = await response.json()

import { request } from 'node:https'

const body = JSON.stringify({ limit: 25 })

const req = request(
  new URL('https://api.getsillage.com/api/v2/workspace/signals/query'),
  {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.SILLAGE_API_KEY}`,
      'Content-Type': 'application/json',
      'Content-Length': Buffer.byteLength(body),
    },
  },
  (res) => {
    let data = ''
    res.on('data', (chunk) => {
      data += chunk
    })
    res.on('end', () => {
      console.log(JSON.parse(data))
    })
  },
)

req.write(body)
req.end()

import os
import requests

response = requests.post(
    "https://api.getsillage.com/api/v2/workspace/signals/query",
    json={"limit": 25},
    headers={"Authorization": f"Bearer {os.environ['SILLAGE_API_KEY']}"},
    timeout=30,
)
response.raise_for_status()
result = response.json()

Example response

200 OK

{
  "data": [
    {
      "id": 101,
      "signal_type": "keywordDetection",
      "data": {
        "content_id": 5100,
        "author": {
          "type": "profile",
          "full_name": "Jane Doe",
          "headline": "VP Product at Acme",
          "linkedin_url": "https://linkedin.com/in/janedoe"
        },
        "keywords_found": ["AI"]
      },
      "detected_at": "2026-06-01T10:00:00.000Z",
      "signal_date": null,
      "lead_id": 456,
      "company_id": 789,
      "agent_id": 12,
      "source_url": "https://www.linkedin.com/feed/update/urn:li:activity:7100000000000000000/",
      "author": {
        "full_name": "Jane Doe",
        "headline": "VP Product at Acme",
        "linkedin_url": "https://linkedin.com/in/janedoe"
      },
      "excerpt": "Excited to share how AI is transforming our product roadmap this quarter."
    }
  ],
  "meta": {
    "next_cursor": "eyJkZXRlY3RlZEF0IjoiMjAyNi0wNi0wMVQxMDowMDowMC4wMDBaIiwiaWQiOjEwMX0=",
    "has_more": true
  }
}

To fetch the next page, pass next_cursor as cursor in the body of the subsequent request. When has_more is false, you have reached the last page and next_cursor will be null.

For keyword detections, data.content_id is the ID of the content the keyword matched in (usable with the Contents endpoints), and data.author describes who published it, discriminated by type: "profile" (a person — full_name, headline, linkedin_url) or "company" (a company page — company_name, linkedin_url). author is null when the publisher is unknown.

The top-level source_url, author, and excerpt fields are convenience shortcuts to the most relevant link, person, and text extract already present somewhere in data (or, for a few signal types, only reachable outside the current data shape) — read them directly instead of digging through the type-specific data payload. The top-level author is not always the same object as data.author: for detections where the source content and the person are separate concepts (e.g. a comment left by someone else on a tracked post), the top-level author follows a fixed per-type priority so it consistently points at the person behind the source content.

Detection object fields (V2SignalDetection)

Watchlist comment detections

Detections produced by watchlist agents (signal types ending in InboundComment or OutboundComment, e.g. competitorInboundComment) use a dedicated data shape: the comment on one side (interaction), the post it was left on the other (post). Each side carries a content_id — the ID of the matching content in your workspace, usable with the Contents endpoints. content_id is null when no matching content exists in your workspace.

{
  "interaction": {
    "type": "comment",
    "content_id": 5001,
    "author": {
      "full_name": "Jane Doe",
      "linkedin_url": "https://linkedin.com/in/janedoe",
      "headline": "VP Product at Acme"
    }
  },
  "post": {
    "content_id": 5002,
    "author": {
      "full_name": "John Smith",
      "linkedin_url": "https://linkedin.com/in/johnsmith",
      "headline": "Head of Sales at Widgets"
    }
  }
}

Errors

Error responses use RFC 9457 problem documents with Content-Type: application/problem+json:

{
  "type": "https://docs.getsillage.com/errors/not-found",
  "title": "Not Found",
  "status": 404,
  "detail": "No matching company found for the supplied identifiers.",
  "instance": "/api/v2/workspace/signals/query"
}