Overview
Enrichments answer research questions about companies and contacts — prebuilt types at per-type prices, custom questions in your own answer shape.
An enrichment answers a research question about a company or contact. Each run researches the live web, grounds its answer in public evidence (with source citations where the type provides them), and returns JSON you can score, route, or sync into a CRM without post-processing.
Five prebuilt types cover the questions teams ask most often: pass a company domain and get a structured answer with a documented schema. When your question isn't one of the five, a custom enrichment lets you ask it in your own words with your own answer shape. GET /v1/enrichment-types returns this catalogue machine-readably — keys, schemas, prices, and execution modes.
Available types
| Type | Key | Answers | Credits |
|---|---|---|---|
| Funding | funding | Most recent funding round and public/IPO status | 0.3 |
| M&A | mna | Whether the company was acquired or made acquisitions | 0.75 |
| Tech stack | tech-stack | Which ERP/CRM it uses, or whether it uses a specific technology | 0.75 |
| Open jobs | open-jobs | What the company is currently hiring for | 0.5 |
| Firmographics | firmographics | Base company profile plus a refined Saber category | 0.6 |
| Custom | — | Your own research question, in the answer shape you define | 2 |
| Work email | work-email | A contact's verified work email (POST /v1/contacts/enrich/work-email) | 0.1 |
Prices are the standard rate card, charged per fresh result — repeat calls served from the cache are free, and failed runs are never charged. See /pricing for the current card.
How a run completes
POST /v1/companies/enrich/{type} returns the enrichment_run envelope:
202 AcceptedwithLocation: /v1/enrichment-runs/{runId}— a fresh run started; poll the run for the result, or pass awebhookUrlto have the completed result delivered.200 OKinline — the answer was served from the cache (free).
GET /v1/enrichment-runs lists runs across both entity types with common filters.
Migrating from the Signals API
The old "Signals API" is not the new "Signals". The question-answering endpoints previously called signals are now enrichments — same contracts, same answer schemas, new names and per-type prices. The word signal now means something else: an occurrence emitted by a monitor (a funding round detected, an answer that changed). If you see signal in the new surface, think "something happened", not "a research answer".
The legacy routes keep working at their existing prices until their announced sunset — the custom and prebuilt signal routes stay at 2 credits per answer, while find-email stays at 0.1, summaries stay free, and the subscription families keep their own watch and discovery rates. Their responses carry Deprecation and successor Link headers so tooling can discover the mapping:
| Legacy route | Successor |
|---|---|
POST /v1/signals/{key} (and /sync/{key}) | POST /v1/companies/enrich/{type} |
POST /v1/companies/signals[/sync|/batch] | POST /v1/companies/enrich/custom[/batch] |
POST /v1/contacts/signals[/sync] | POST /v1/contacts/enrich/custom |
POST /v1/contacts/find-email | POST /v1/contacts/enrich/work-email |
POST /v1/companies/signals/summaries | POST /v1/companies/summaries |
/v1/companies/signals/subscriptions/*, /v1/market-signals/* | /v1/monitors/* |
One migration step per integration: swap the path, read the enrichment_run envelope, and enjoy the per-type price.