Signals

Synchronous form of the Funding signal (POST /v1/signals/funding): creates the signal and blocks until it completes (or the timeout is reached), returning the result in the same response. Recommended for interactive and agent workflows. If you supply a webhookUrl, the completed signal is still delivered to it in addition to this response — omit it unless you want both.

The completed answer (answer.jsonSchema) conforms to FundingSignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Header Parameters

Response Body

Summarise a company's most recent funding and public/IPO status from a domain.

The AI confirms sources belong to the company at that domain, reports the latest primary equity round (never a secondary, tender, or debt event), and flags a completed IPO / direct listing / SPAC as isPublic: true with latestRound: "IPO".

This is the async endpoint: it returns 201 immediately with a processing signal. Poll GET /v1/companies/signals/{signalId} or supply a webhookUrl to receive the completed result. For a single blocking request, use POST /v1/signals/sync/funding.

The completed answer (answer.jsonSchema) conforms to FundingSignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Response Body

Synchronous form of the M&A signal (POST /v1/signals/mna): creates the signal and blocks until it completes, returning the result in the same response. If you supply a webhookUrl, the completed signal is still delivered to it in addition to this response — omit it unless you want both.

The completed answer (answer.jsonSchema) conforms to MAndASignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Header Parameters

Response Body

Detect whether a company was acquired, or made acquisitions, in the recent window — counterparty, deal status, and value where disclosed.

Counts only true acquisitions (control transfer): minority investments, funding rounds, and partnerships are excluded. role distinguishes the queried company being bought (acquiree, reported at any age) from it buying others (acquirer, last 24 months only). An announced deal that later collapsed is terminated, never completed. An acquisition backed only by a data aggregator with no primary corroboration stays rumored and does not count as detected.

This is the async endpoint. For a single blocking request, use POST /v1/signals/sync/mna.

The completed answer (answer.jsonSchema) conforms to MAndASignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Response Body

Synchronous form of the Tech signal (POST /v1/signals/tech): creates the signal and blocks until it completes, returning the result in the same response. Supply exactly one of category or technology. If you supply a webhookUrl, the completed signal is still delivered to it in addition to this response — omit it unless you want both.

The completed answer (answer.jsonSchema) conforms to TechSignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Header Parameters

Response Body

Detect which system(s) a company currently uses in a technology category, verified with public web evidence.

Supply exactly one typed parameter:

• category — a coarse category (erp or crm). Returns every system detected in that category, with the current system of record in primary.
• technology — a specific product (free text resolved to a canonical slug, e.g. salesforce, SAP S/4HANA). Returns a one-element technologies list whose status carries the verdict (active, churned, or not_found).

Vendor data is a prior, not the answer. Technographics detections enter the agent loop only as leads to verify; every reported technology must cite public web evidence — a job posting, engineering blog, docs, a case study, or a live website fingerprint. A vendor-only hint that can't be corroborated surfaces as status: not_found, never as a confirmed finding.

This is the async endpoint. For a single blocking request, use POST /v1/signals/sync/tech.

The completed answer (answer.jsonSchema) conforms to TechSignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Response Body

Synchronous form of the Open Jobs signal (POST /v1/signals/open-jobs): creates the signal and blocks until it completes, returning the result in the same response. If you supply a webhookUrl, the completed signal is still delivered to it in addition to this response — omit it unless you want both.

The completed answer (answer.jsonSchema) conforms to OpenJobsSignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Header Parameters

Response Body

Summarise what a company is hiring for from public job postings: how many roles are open, the function areas and technologies behind them, and where.

openings is the true total matching the trailing 90-day window (the job search tool's reported match count), not the number of sampled listings. topTitles, hiringThemes, techHiringFor, and locations are drawn from a small sample and are examples, not a proportional breakdown. hiringThemes maps roles onto a fixed function taxonomy so the field stays filterable and stable.

This is the async endpoint. For a single blocking request, use POST /v1/signals/sync/open-jobs.

The completed answer (answer.jsonSchema) conforms to OpenJobsSignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Response Body

Synchronous form of the Firmographics signal (POST /v1/signals/firmographics): creates the signal and blocks until it completes, returning the result in the same response. If you supply a webhookUrl, the completed signal is still delivered to it in addition to this response — omit it unless you want both.

The completed answer (answer.jsonSchema) conforms to FirmographicsSignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Header Parameters

Response Body

Return a company's base profile — headcount, size band, entity type, founded year, HQ location — plus a Saber-derived category that refines the coarse public industry tag, with cited web evidence.

The differentiator is saberCategory: a generalized→niche classification that corrects the over-broad public industry label (which tags many firms simply as "Software") using the company's own site and product pages. segments captures who the company sells to (B2B, B2C, B2B2C, B2G, C2C). Authoritative enrichment priors (headcount, LinkedIn followers, type, founded year, website) are copied verbatim when known and researched only when absent — never guessed.

This is the async endpoint. For a single blocking request, use POST /v1/signals/sync/firmographics.

The completed answer (answer.jsonSchema) conforms to FirmographicsSignalAnswer. Cost: 2 credits, charged once per result delivered to your organization — your own repeat calls served from cache are free, and failed runs are never charged.

Response Body

⭐ This is the recommended way to create signals and get results instead of async + webhooks.

Creates a signal and waits synchronously for it to complete, returning the result in the same request. This endpoint blocks until the signal processing finishes or a timeout is reached.

Why Use the Sync Endpoint?

Advantages over async + webhooks:

• ✅ Get results immediately in one request
• ✅ No webhook hosting required
• ✅ No polling implementation needed
• ✅ Simpler integration
• ✅ Better for synchronous workflows

How It Works

1. Send your signal creation request (same payload as regular POST /v1/companies/signals)
2. The endpoint creates the signal and polls for completion
3. Returns the completed signal with results when processing finishes
4. If timeout is reached, returns the latest status (processing)

Timeout Configuration

• Default timeout: 870 seconds (server-configured, applies when the header is absent)
• Max timeout: 870 seconds — higher values are clamped
• Custom timeout: Use X-Sbr-Timeout-Sec header to set custom timeout (up to max)
• Error on timeout: Use X-Sbr-Timeout-Error: true header to return 408 on timeout instead of latest status

Response Codes

• 200 OK - Signal completed, or timeout reached with the still-processing signal in the body (check status)
• 408 Request Timeout - Timeout reached (when X-Sbr-Timeout-Error: true)

Using with Templates

Use signalTemplateId instead of defining questions inline for standardized research:

{  "domain": "acme.com",  "signalTemplateId": "a12b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d"}

Templates let you reuse research questions, qualification criteria, and answer types across multiple companies. Create templates via POST /v1/companies/signals/templates.

Credits

Each signal charges 2 credits. Repeat calls served from the 12-hour cache (see Caching Behavior on POST /v1/companies/signals) do not consume additional credits, and failed runs are never charged — reserved credits are released.

Header Parameters

{  "yes": "good",  "no": "disqualified"}

{  "ranges": [    { "rangeStart": 0, "rangeEnd": 100, "answerValue": "neutral" },    { "rangeStart": 101, "rangeEnd": 1000, "answerValue": "good" }  ]}

{  "choices": {    "salesforce": { "answerValue": "good", "label": "Salesforce" },    "hubspot": { "answerValue": "neutral", "label": "HubSpot" },    "none": { "answerValue": "disqualified", "label": "No CRM" }  }}

Response Body

Retrieve all signals with optional filtering by domain or companyId, pagination and filtering. Results are sorted by creation date (latest first).

Note: For creating signals and getting results in one step, we recommend using the /v1/companies/signals/sync endpoint instead, which returns the result directly.

Query Parameters

Response Body

Submit a domain and question to create a new research signal. The AI will analyze the domain and provide a structured answer based on the specified answer type.

When to Use This Endpoint

Use this endpoint for event-driven architectures where you need webhook notifications. For simpler integrations, use the /v1/companies/signals/sync endpoint (recommended) which returns results immediately.

Webhooks

Configure webhooks by including a webhookUrl parameter in your request.

What we deliver: One logical delivery per signal, once it reaches a terminal state — retries (below) mean your endpoint may see it as more than one HTTP request, all carrying the same X-Idempotency-Key. The body is the signal object itself — there is no event envelope and no event-type header, so read the body's status (completed or failed) to tell the outcome. One exception: a Slack webhook URL (https://hooks.slack.com/services/…) receives a formatted Slack message instead of the raw signal object.

Webhook security: Deliveries are not signed. Treat the payload as untrusted: use an unguessable webhookUrl, and re-read the signal via GET /v1/companies/signals/{signalId} before acting on it. Each delivery carries an X-Idempotency-Key header you can use to discard duplicates.

Webhook reliability:

• Deliveries that fail to connect, time out, or return 5xx are attempted up to 5 times in total with exponential backoff
• A 4xx response is treated as a permanent rejection and is not retried
• A webhookUrl whose host does not resolve in DNS is rejected without retry, so point it at a hostname that already resolves
• Webhook requests timeout after 25 seconds
• Your endpoint should respond with 2xx status code
• A failed delivery never fails the signal: the answer is still produced, billed, and readable via the API

Caching Behavior

Your response will be cached for up to 12 hours by default, unless you set the forceRefresh flag to true.

Cache is based on a hash of the following fields: domain (or contactProfileUrl for contact signals), question, answer type, verification mode, and output schema (if provided). Changing any of these fields will create a new signal. We will not send you the webhook if you hit the cache, even if the webhook URL in the payload is different from the original request.

Instead you will receive the latest status of the signal immediately in the response.

Using with Templates

Use signalTemplateId instead of defining questions inline for standardized research:

{  "domain": "acme.com",  "signalTemplateId": "a12b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d",  "webhookUrl": "https://myapp.com/webhooks/signals"}

Templates let you reuse research questions, qualification criteria, and answer types across multiple companies. Create templates via POST /v1/companies/signals/templates.

Credits

Each signal charges 2 credits. Repeat calls served from the cache (see Caching Behavior above) do not consume additional credits, and failed runs are never charged — reserved credits are released.

{  "yes": "good",  "no": "disqualified"}

{  "ranges": [    { "rangeStart": 0, "rangeEnd": 100, "answerValue": "neutral" },    { "rangeStart": 101, "rangeEnd": 1000, "answerValue": "good" }  ]}

{  "choices": {    "salesforce": { "answerValue": "good", "label": "Salesforce" },    "hubspot": { "answerValue": "neutral", "label": "HubSpot" },    "none": { "answerValue": "disqualified", "label": "No CRM" }  }}

Response Body

Submit multiple signals and domains to create signals using a Cartesian product pattern. Each signal is combined with each domain to create individual signals.

Two ways to create batch signals:

1. Inline Questions: Define questions directly in the request for ad-hoc research without creating templates
2. Using Templates (recommended for reusability): Reference pre-created templates by ID for consistent, reusable questions

Cartesian Product Logic:

• If you submit 2 templates and 3 domains, the system creates 6 signals (2 × 3)
• Sync mode (default): Maximum 100 resulting signals (templates × domains ≤ 100)
• Async mode (async: true): Maximum 20,000 resulting signals (templates × domains ≤ 20,000)

Sync Mode (default):

• Returns inline results with individual signal statuses
• Maximum 100 signals per batch
• Returns 202 with results[] array

Async Mode (async: true):

• For large batches up to 20,000 signals
• Returns immediately with a batchId for tracking
• Signals are processed in background chunks
• Returns 202 with batchId, totalSignals, status: "accepted"
• Poll /v1/companies/signals/batches/status?domain=... for progress

Partial Failure Handling (sync mode):

• Individual signal failures don't block other signals from processing
• Each signal in the response includes its own status (accepted or failed)
• Returns 202 if at least one signal is scheduled successfully
• Returns 422 if all signals failed to be scheduled

Processing:

• All signals are processed asynchronously
• No guarantee of processing order
• Use the /v1/companies/signals/sync endpoint (recommended) to retrieve results as they complete

Webhooks:

• Each signal in the batch can include a webhookUrl to receive notifications on completion
• Webhooks fire individually per signal as each one completes processing
• Each signal gets one logical delivery, retried on failure — dedupe HTTP requests on the X-Idempotency-Key header
• The delivery body is the signal object itself, with no event envelope — read its status (completed or failed) for the outcome. A Slack webhook URL receives a formatted Slack message instead
• Deliveries are not signed

Caching Behavior:

• Signals are cached based on a hash of domain, question, answer type, verification mode, and output schema (if provided)
• If a matching cached result exists, the cached response is returned immediately and no webhook is sent
• To force fresh processing (and webhook delivery), set forceRefresh: true on individual signals

Automatic Summary Generation:

• Set generateSummaryOnComplete to true to automatically generate summaries when all signals in the batch complete
• Summaries are generated per domain (one summary per unique domain in the batch)
• Summary generation is triggered automatically once all signals for a domain have completed
• Use the /v1/companies/signals/summaries endpoint to retrieve generated summaries

Credits: 2 credits per signal created. The batch expands every question across every company — 2 questions × 3 companies creates 6 signals and charges 12 credits. Cached results and failed runs are not charged.

Response Body

⭐ This is the recommended way to create contact signals and get results instead of async + webhooks.

Creates a contact signal and waits synchronously for it to complete, returning the result in the same request. Works identically to the company signals sync endpoint but for contact-based signals.

Why Use the Sync Endpoint?

Advantages over async + webhooks:

• ✅ Get results immediately in one request
• ✅ No webhook hosting required
• ✅ No polling implementation needed
• ✅ Simpler integration
• ✅ Better for synchronous workflows

How It Works

1. Send your signal creation request (same payload as regular POST /v1/contacts/signals)
2. The endpoint creates the signal and polls for completion
3. Returns the completed signal with results when processing finishes
4. If timeout is reached, returns the latest status (processing)

Timeout Configuration

• Default timeout: 870 seconds (server-configured, applies when the header is absent)
• Max timeout: 870 seconds — higher values are clamped
• Custom timeout: Use X-Sbr-Timeout-Sec header to set custom timeout (up to max)
• Error on timeout: Use X-Sbr-Timeout-Error: true header to return 408 on timeout instead of latest status

Response Codes

• 200 OK - Signal completed, or timeout reached with the still-processing signal in the body (check status)
• 408 Request Timeout - Timeout reached (when X-Sbr-Timeout-Error: true)

Using with Templates

Use signalTemplateId instead of defining questions inline for standardized research:

{  "contactProfileUrl": "https://linkedin.com/in/johndoe",  "signalTemplateId": "a12b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d"}

Templates let you reuse research questions, qualification criteria, and answer types across multiple contacts. Create templates via POST /v1/companies/signals/templates.

Credits

Each signal charges 2 credits. Repeat calls served from the cache do not consume additional credits, and failed runs are never charged — reserved credits are released.

Header Parameters

Response Body

Retrieve all contact signals with optional filtering by LinkedIn URL, pagination and filtering. Results are sorted by creation date (latest first).

Note: For creating contact signals and getting results in one step, we recommend using the /v1/contacts/signals/sync endpoint instead, which returns the result directly.

Query Parameters

Response Body

Submit a LinkedIn URL and question to create a new research signal for an individual contact. The AI will analyze the contact's profile and provide a structured answer based on the specified answer type.

Contact signals work similarly to company signals but focus on individual contacts using their LinkedIn profile URLs.

When to Use This Endpoint

Use this endpoint for event-driven architectures where you need webhook notifications. For simpler integrations, use the /v1/contacts/signals/sync endpoint (recommended) which returns results immediately.

Webhooks

Configure webhooks by including a webhookUrl parameter in your request.

What we deliver: One logical delivery per signal, once it reaches a terminal state — retries (below) mean your endpoint may see it as more than one HTTP request, all carrying the same X-Idempotency-Key. The body is the signal object itself — there is no event envelope and no event-type header, so read the body's status (completed or failed) to tell the outcome. One exception: a Slack webhook URL (https://hooks.slack.com/services/…) receives a formatted Slack message instead of the raw signal object.

Webhook security: Deliveries are not signed. Treat the payload as untrusted: use an unguessable webhookUrl, and re-read the signal via GET /v1/contacts/signals/{signalId} before acting on it. Each delivery carries an X-Idempotency-Key header you can use to discard duplicates.

Webhook reliability:

• Deliveries that fail to connect, time out, or return 5xx are attempted up to 5 times in total with exponential backoff
• A 4xx response is treated as a permanent rejection and is not retried
• A webhookUrl whose host does not resolve in DNS is rejected without retry, so point it at a hostname that already resolves
• Webhook requests timeout after 25 seconds
• Your endpoint should respond with 2xx status code
• A failed delivery never fails the signal: the answer is still produced, billed, and readable via the API

Using with Templates

Use signalTemplateId instead of defining questions inline for standardized research:

{  "contactProfileUrl": "https://linkedin.com/in/johndoe",  "signalTemplateId": "a12b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d",  "webhookUrl": "https://myapp.com/webhooks/signals"}

Templates let you reuse research questions, qualification criteria, and answer types across multiple contacts. Create templates via POST /v1/companies/signals/templates.

Contact signals work similarly to company signals but focus on individual contacts using their LinkedIn profile URLs.

Credits

Each signal charges 2 credits. Repeat calls served from the cache do not consume additional credits, and failed runs are never charged — reserved credits are released.

Response Body

Retrieve the current status and results of a signal. If the signal is completed, the response will include the AI-generated answer, confidence score, and sources.

Path Parameters

Response Body

Retrieve all signal executions that were triggered by a specific signal subscription. Returns the same paginated response as GET /v1/companies/signals but filtered to a single subscription. Results are sorted by creation date (latest first).

Path Parameters

Query Parameters

Response Body

Retrieve the current status and results of a contact signal. If the signal is completed, the response will include the AI-generated answer, confidence score, and sources.

Path Parameters

Response Body