V1 Client APIs

Sign up as a new user or sign back in to retrieve your API key. Sends a 6-digit verification code to the provided email address. After receiving the code, call the verify endpoint to complete authentication and receive your API key. - **New users**: creates your account. API key is issued after verification. - **Existing users**: use this to recover your API key if lost. Verify with the OTP to get your existing key back.

Verify your email with the 6-digit code sent during sign-up. On success, returns your API key: - **New users**: a freshly generated API key for your account. - **Existing users**: your existing API key is returned (use this to recover a lost key). The verification code expires after 24 hours. You have up to 10 attempts per code. If you exhaust all attempts, call sign-up again to receive a new code.

List accounts with optional filters and pagination. **Request Body (optional):** - **filters**: Filter accounts by CRM status, employee count, funding stage, etc. - **pagination**: Control page size (limit) and offset for pagination. - limit: 1-500, default 50 - offset: default 0

Search accounts by name or domain with fuzzy matching.

Search for companies by describing their traits or characteristics. Use natural language to find companies matching specific criteria like: - **Industry**: "healthcare companies", "fintech startups" - **Products**: "companies with voice AI products", "payment processing platforms" - **Business model**: "B2B SaaS companies", "companies that sell to restaurants" - **Technology**: "companies using Kubernetes", "AI-first startups" Returns companies ranked by relevance with similarity scores.

Discovery endpoint for the firmographic filters accepted by the lookalike search endpoints — `GET /api/v1/account/search-lookalikes` (sync) and `POST /api/v1/account/search-lookalikes-bulk` (async): - **min_employees / max_employees** — inclusive integer bounds (>= 0, no upper limit). - **funding_stages** — the exact stage labels accepted; input is matched case-insensitively and canonicalized to these. - **locations** — supported HQ-country filters as `{code, name}`; pass the ISO 3166-1 alpha-3 `code` (e.g. `USA`, `GBR`) in `locations`. Static and fast — mirrors `GET /api/v2/tech/country-options`. Use it to populate filter pickers or to validate input before calling search.

Free, fast company search for finding lookalike accounts.

Start an async bulk lookalike search (up to 10000 companies). Returns a ``job_id`` immediately. Poll ``GET /api/v1/account/search-lookalikes-bulk/{job_id}`` for status and to page through results. Cancel a running job with ``POST /api/v1/account/search-lookalikes-bulk/{job_id}/cancel``. Credits are pre-checked against the requested ``limit`` here, then charged on the actual returned count when the job completes (or the delivered count if cancelled).

Combined status + results for a bulk lookalike job. Returns the job status, manifest, live progress (``processed`` + ``progress_message``), and one page of results in a single call. Check ``status`` for a terminal state (``completed``/``failed``/``cancelled``) — NOT ``next_cursor == null``, since a still-``running``/``cancelling`` job can have a null ``next_cursor`` simply because later pages haven't been written yet. A ``cancelling`` status is transient (a cancel was requested); the job settles to ``cancelled`` with a ``partial`` manifest of the pages already delivered.

Request cancellation of a running/pending bulk lookalike job. Flips the job to a transient ``cancelling`` state; the worker stops at its next batch boundary, flushes whatever pages it has written, charges ONLY the delivered count (no credits for the abandoned remainder), and finalizes as ``cancelled``. Already-terminal jobs (``completed``/``failed``/``cancelled``) return 409. Poll ``GET /api/v1/account/search-lookalikes-bulk/{job_id}`` for the final state and the partial results.

Resolve up to 100 companies against the OpenFunnel companies OpenSearch index. Each item may carry any subset of ``name`` / ``domain`` / ``linkedin_url``: - **domain** and **linkedin_url** are exact matches and return ALL companies that share that identifier (e.g. a parent and a satellite page). Domain matches any of the company's domains (primary or secondary). - **name** is a fuzzy, ranked full-text search over the company name fields; returns up to 10 candidates with relevance scores. Matches within an item are deduped by ``company_id`` (precedence: linkedin > domain > name). A returned ``company_id`` can be passed straight back into ``/search-lookalikes`` as a seed. No credits are charged.

List account IDs matching either inline `filters` or a saved view. Provide ONE of: - `filters` (V2 field names, see GET /api/v2/account/filters), or - `view_id` — the saved view's stored filters are applied instead. `page`, `page_size`, `sort_key`, and `sort_direction` apply in both modes. Returns 404/403 when `view_id` does not exist / belongs to another user, and 422 when both `filters` and `view_id` are provided.

Get signal details by ID with optional date filtering.

Edit a signal's settings. Omitted fields are left unchanged. Editable fields: - `signal_name` — min 3 characters, unique within the workspace (400 otherwise) - `enable_run_daily` — toggles daily recurring runs - `max_credit_limit` — per-run credit budget; explicit `null` removes the limit - `enable_safe_crm_sync` — safe CRM sync toggle - `auto_enrich_people_emails` — auto email enrichment toggle - `enable_advanced_people_finder` — advanced LLM-based people finder toggle (charges credits) Authorization mirrors the delete endpoint: the signal owner may edit; in TEAM mode the domain superadmin may also edit team members' signals (403 otherwise). Returns the updated signal.

Delete one or more signals. Deletion is queued in the background per signal: the signal is paused and unlinked from the user, its discovered signals are detached, and accounts left with no other linked signals are unlinked (imported accounts are kept). Authorization mirrors the internal delete: the signal owner may delete; in TEAM mode the domain superadmin may also delete team members' signals. Always returns 200 — partial batches don't fail wholesale. Each signal that could not be deleted gets a structured entry in `errors` with an `error_code` (`SIGNAL_NOT_FOUND`, `NOT_RESOURCE_OWNER`) and message. `status` is `accepted` (all queued), `partial` (some queued, some failed), or `failed` (nothing queued).

Get audience details by ID.

List audiences with optional pagination.

Get chronological activity timeline for an account. Returns events from account_timeline_insights table within the specified time range. Args: account_id: The account ID to get timeline for days: How many days back to look (default 30, max 365) alert_types: Optional comma-separated filter ('openfunnel', 'crm') limit: Maximum events per page (default 50, max 500) offset: Number of events to skip for pagination user_id: Authenticated user ID (from API key) Returns: TimelineResponse with events and pagination metadata

Get alerts (notifications) sent to the authenticated user. Returns notification history with the actual insights from each alert. Always scoped to the individual user who set up the saved view. Use `view_ids` to narrow the history to specific views — e.g. the latest insights a single Live View has alerted on.

Get saved views owned by the authenticated user. Returns both account and people views by default; pass `view_type` to narrow.

Create a saved view (Live View). **view_type** selects what the view filters and which actions it allows: - `"accounts"` (default): filters companies. Supports **slack_notifications**, **webhook_notifications**, **crm_assignment**. Amplemarket is rejected (400). `filters` use the field names from `GET /api/v2/account/filters`. - `"people"`: filters individuals and supports **only amplemarket_sequencing** (enabling Slack / webhook / CRM returns 400). `filters` use the People filter fields from `GET /api/v1/people/filters` (e.g. `seniority_include`, `department_include`, `acct_industry_include`); preview who matches with `POST /api/v1/people/filtered-people`. **Immutable after creation.** When created with an Amplemarket sequence, OpenFunnel adds everyone who currently matches to the sequence and enriches any missing work emails (this uses credits, paced within your monthly allowance). Account-view actions: - **slack_notifications**: notify via DM or in a Slack channel (`target: "channel"` requires `channel_id` from `GET /views/options`). - **webhook_notifications**: POST insight alerts to an HTTPS URL. The response includes `webhook_secret` (HMAC signing secret) **once**, so store it securely. - **crm_assignment**: sync matched accounts to the connected CRM and assign them to a single user (`mode: "single"` + `assignee_id`) or round-robin across users (`mode: "round_robin"` + `assignee_ids`). `override_owner_ids` lists owners whose accounts may be reassigned; accounts owned by anyone else keep their owner. The CRM type is detected automatically. When enabled, a one-time background sync of currently-matching accounts is started immediately. - **amplemarket_sequencing** (people views only): auto-add new matching people to an Amplemarket sequence (`sequence_id` from `GET /views/options`). - **is_default**: make this the default view (clears the previous default of the same view_type). Errors: 400 for invalid/unconnected integrations or an action that doesn't match the view_type (with an actionable message), 409 if a view with the same name already exists.

Export people from accounts represented in alerts for a saved view.

Export accounts from a saved view as CSV.

Get paginated alerts for a saved view owned by the authenticated user.

Get everything needed to build a view's notification / assignment config in a single call: - **slack**: whether Slack is connected and the channels the OpenFunnel bot can post to (use a channel `id` as `slack_notifications.channel_id`). - **crm**: the connected CRM (`salesforce` or `hubspot`) and its users (use a user `id` for `crm_assignment.assignee_id` / `assignee_ids` / `override_owner_ids`). - **amplemarket**: whether Amplemarket is connected and the active sequences (use a sequence `id` as `amplemarket_sequencing.sequence_id`). Each section is independent: a disconnected integration is returned as `connected: false` with an empty list rather than failing the request.

Get a single saved view by ID, including its `view_type`, filters and full action config (Slack / webhook / CRM assignment / Amplemarket). Account-view filters are returned with the `GET /api/v2/account/filters` field names; people-view filters with the `GET /api/v1/people/filters` field names. The webhook signing secret is never returned here; it is only surfaced once, when the webhook is configured or its URL changes. Returns 404 if the view does not exist and 403 if it belongs to another user.

Partially update a saved view. Only fields present in the request are modified; omitted fields keep their current value. `view_type` cannot be changed; requested actions are validated against the view's existing type (people views still accept only Amplemarket; account views still reject it). Notes: - Sending a config object with `enabled: false` turns that action off (e.g. `{"webhook_notifications": {"enabled": false}}` removes the webhook); omitting the object leaves it unchanged. - `filters` must match the view's type (the `GET /api/v2/account/filters` fields for account views, the `GET /api/v1/people/filters` fields for people views) and replaces them entirely. - Changing the webhook URL rotates the signing secret; the new `webhook_secret` is returned once in the response. - Enabling CRM assignment (or changing `filters` while it is enabled) starts a one-time background sync of currently-matching accounts. For a people view, enabling Amplemarket (or changing `filters` while it is enabled) likewise kicks off a one-time enrich+sequence of currently-matching people (credit-spending; idempotent, only net-new matches are added). Errors: 400 for invalid config or an action that doesn't match the view_type, 404/403 for missing/foreign views, 409 on a view name conflict.

Delete a saved view and all of its notification logs. Returns 404 if the view does not exist and 403 if it belongs to another user. This action cannot be undone.

Return all valid option values for creating an ICP. Call this endpoint first to discover the allowed values for each field before calling `/api/v1/icp/create`. **Response fields:** - **employee_ranges**: Valid company size range labels (e.g. "1-10", "11-50"). Pass one or more of these in `employee_ranges` when creating an ICP. - **funding_stages**: Valid funding stage names (e.g. "Seed", "Series A"). Use these for `min_funding` and `max_funding` when creating an ICP. - **locations**: Valid company HQ country/region options with `value` (code) and `label` (display name). Use the `value` field for `location` when creating an ICP. - **sub_locations**: Valid US state and city options with `value` (code) and `label` (display name). Use the `value` field for `sub_locations` when creating an ICP. Only applicable when `location` is exclusively `["us"]`. - **people_locations**: Valid country/region options for targeting people by geography. Use the `value` field for `people_locations` when creating an ICP. - **people_sub_locations**: Valid US state and city options for targeting people by sub-region. Use the `value` field for `people_sub_locations` when creating an ICP. Only applicable when `people_locations` is exclusively `["us"]`.

List all ICP profiles for the authenticated user.

Create a new Ideal Customer Profile (ICP). An ICP defines the target company and people segments for signal discovery. **Before calling this endpoint**, call `GET /api/v1/icp/options` to retrieve all valid values for employee_ranges, funding stages, locations, and sub_locations. **Required fields:** - **name**: A descriptive name for the ICP (e.g., "Mid-market SaaS companies in US"). - **target_roles**: List of job titles or role descriptions to target. Examples: ["Head of Engineering", "VP of Product", "Senior Leaders in Engineering & Product"]. - **employee_ranges**: Company size filters. Provide one or more range labels from the `employee_ranges` list returned by `/api/v1/icp/options`. Multiple ranges are collapsed to an overall min/max employee count internally. - **location**: List of company HQ location codes. Use the `value` field from the `locations` list returned by `/api/v1/icp/options` (e.g., ["us", "uk", "ca"]). **Optional fields:** - **min_funding** / **max_funding**: Funding stage range. Both must be provided together. Use values from the `funding_stages` list returned by `/api/v1/icp/options`. - **employee_count_funding_config**: How to combine employee count and funding criteria. Only valid when funding is set. Values: `"AND"` (company must match both employee count AND funding stage) or `"OR"` (company must match either). Omit or set to null if no combination logic is needed. - **sub_locations**: US state or city codes. Use the `value` field from the `sub_locations` list returned by `/api/v1/icp/options` (e.g., ["ca", "san-francisco-ca", "ny"]). **Only applicable when `location` is exclusively `["us"]`.** - **people_locations**: Geographic filter for target people. Use the `value` field from the `people_locations` list returned by `/api/v1/icp/options` (e.g., ["us", "ca"]). - **people_sub_locations**: Sub-region codes for people locations. Use the `value` field from the `people_sub_locations` list returned by `/api/v1/icp/options` (e.g., ["san-francisco-ca", "austin-tx"]). **Only applicable when `people_locations` is exclusively `["us"]`.**

Update an existing Ideal Customer Profile (ICP). Only the fields included in the request body will be modified — all other fields remain unchanged. The `id` field is always required to identify which ICP to update. **Before calling this endpoint**, call `GET /api/v1/icp/options` to retrieve all valid values for employee_ranges, funding stages, locations, and sub_locations. **Required fields:** - **id**: The numeric ID of the ICP to update (returned by `/api/v1/icp/list` or `/api/v1/icp/create`). **Updatable fields (all optional — include only what you want to change):** - **name**: A descriptive name for the ICP. Must be non-empty and unique among the user's ICPs. - **target_roles**: List of job titles or role descriptions to target. Must contain at least one role if provided. Examples: ["Head of Engineering", "VP of Product"]. - **employee_ranges**: Company size filters. Provide one or more range labels from the `employee_ranges` list returned by `/api/v1/icp/options`. Must contain at least one range if provided. - **location**: List of company HQ location codes. Use the `value` field from the `locations` list returned by `/api/v1/icp/options` (e.g., ["us", "uk"]). Must contain at least one location if provided. - **min_funding** / **max_funding**: Funding stage bounds. Each can be updated independently. Set to `null` to clear (stored as `"Any"`). A value of `"Any"` means no constraint on that bound. Use values from the `funding_stages` list returned by `/api/v1/icp/options`. - **employee_count_funding_config**: How to combine employee count and funding criteria. Values: `"AND"` or `"OR"`. Only valid when funding is set. Set to `null` to clear. - **sub_locations**: US state or city codes. Use the `value` field from the `sub_locations` list returned by `/api/v1/icp/options` (e.g., ["ca", "san-francisco-ca"]). **Only applicable when `location` is exclusively `["us"]`.** Set to `null` or `[]` to clear. If changing `location` away from `["us"]`, you must also clear this field. - **people_locations**: Geographic filter for target people. Use the `value` field from the `people_locations` list returned by `/api/v1/icp/options`. Set to `null` or `[]` to clear. - **people_sub_locations**: Sub-region codes for people locations. Use the `value` field from the `people_sub_locations` list returned by `/api/v1/icp/options`. **Only applicable when `people_locations` is exclusively `["us"]`.** Set to `null` or `[]` to clear. If changing `people_locations` away from `["us"]`, you must also clear this field. **Cross-field validation:** - `sub_locations` requires `location` to be `["us"]` (checked against the final merged state, not just the request). - `people_sub_locations` requires `people_locations` to be `["us"]`. - `employee_count_funding_config` requires at least one of `min_funding` or `max_funding` to be a non-`"Any"` value.

Return the authenticated user's credit balance. Requires only a valid `X-API-Key` — this endpoint declares no scopes (`scopes=[]`), so any authenticated caller can reach it regardless of which product/primitive scopes are granted to them. **Response fields:** - **total_credits**: The credit allowance for this billing account (`max_openfunnel_credits`). - **credits_used**: Credits consumed in the current billing window. - **credits_left**: `total_credits - credits_used`, floored at 0. Credits are resolved against the caller's billing account, mirroring how usage is enforced elsewhere: - **INDIVIDUAL / gmail / FREE / TOPUP**: scoped to the user; FREE/TOPUP count lifetime usage, paid users count the current monthly billing window. - **TEAM** (paid, non-gmail domain): usage is pooled across all members of the domain and the allowance is the domain's highest `max_openfunnel_credits`.

Enrich a company account with firmographic data. Looks up the company by domain and fills in firmographic fields: employee count, funding stage, HQ location (city/region/country), industry, revenue, LinkedIn follower count, and description. **Behavior:** - If the account already exists for this user, missing firmographic fields are backfilled - If the account does not exist, a new account is created with all available data - Returns synchronously (~50-200ms) **Fields enriched:** | Field | Description | |-------|-------------| | `employee_count` | Estimated employee count | | `funding_stage` | Normalized funding stage (seed, series_a, ipo, etc.) | | `location` | Formatted HQ location string (e.g. "San Francisco, California, US") | | `hq_city` | HQ city name | | `hq_region` | HQ state/region name | | `hq_country` | HQ country name or code | | `industry` | Primary industry | | `revenue_usd` | Estimated annual revenue in USD | | `linkedin_follower_count` | LinkedIn page follower count | | `description` | Company description | **Example request:** ```json {"domain": "stripe.com"} ``` **Error codes:** - `INVALID_REQUEST` (400) — Domain is empty or invalid - `INTERNAL_ERROR` (500) — Internal service failure

Start an async job to enrich multiple company accounts with firmographic data. Accepts up to 500 domains. Domains are deduplicated and normalized. Returns a ``job_id`` immediately for polling. **Flow:** 1. Call this endpoint with ``domains`` list -> receive ``job_id`` 2. Poll ``GET /api/v1/enrich/accounts/{job_id}`` every 3-5 seconds 3. When ``status`` is ``"completed"``, the ``result`` field contains per-domain enrichment data

Poll the status of a batch account enrichment job. Returns the current status and, when completed, per-domain results with account IDs, fields updated, and whether each account was new or existing. **Status values:** - ``pending`` — Job created, not yet started - ``running`` — Enrichment in progress - ``completed`` — All done; check ``result`` for per-domain data - ``failed`` — Job failed; check ``error_message``

Start an async job to discover people at a company using Seniority & Department Filters. This typically takes 1-5 seconds. **Flow:** 1. Call this endpoint with ``account_id`` + filters -> receive ``job_id`` 2. Poll ``GET /api/v1/enrich/fast-people-enrichment/{job_id}`` every 2-3 seconds 3. When ``status`` is ``"completed"``, the ``result`` field contains discovered people ids 4. Use the Get People Endpoint ``/api/v1/people/batch`` to get the people details **People locations:** - Optional list of 2-letter country codes (e.g. ``["us", "uk", "eu"]``) - Available country codes can be fetched from ``GET /api/v1/icp/options`` **Credit costs:** - Credits charged per **new** person stored - Optionally limit spend with ``max_credit_limit`` **Example request:** ```json { "account_id": 12345, "seniority_filters": ["VP", "DIRECTOR"], "department_filters": ["ENGINEERING", "PRODUCT"] } ``` **Error codes:** - ``INVALID_REQUEST`` (400) — Empty filters or credits exceeded - ``ACCOUNT_NOT_FOUND`` (404) — Account ID not found - ``CREDITS_EXCEEDED`` (400) — Monthly credit limit reached

Poll the status of a fast people enrichment job. Returns the current status and, when completed, the list of discovered people. **Status values:** - ``pending`` — Job created, not yet started - ``running`` — Discovery in progress - ``completed`` — All done; ``result`` contains discovered people - ``failed`` — Job failed; check ``error_message`` **Polling recommendation:** Every 2-3 seconds. Typically completes in 1-5 seconds. Post completion, this API returns the people ids of the discovered people. Use the Get People Endpoint ``/api/v1/people/batch`` to get the people details.

Start an async job to enrich people with email and/or phone data. Looks up each person via their LinkedIn URL and returns a ``job_id`` immediately for polling. **Flow:** 1. Call this endpoint with ``people_ids`` → receive ``job_id`` 2. Poll ``GET /api/v1/enrich/people/{job_id}`` every 3-5 seconds 3. When ``status`` is ``"completed"``, the ``result`` field contains per-person email/phone data **Credit costs:** - Email enrichment: credits charged per email **successfully found** (not per attempt) - Phone enrichment: credits charged per phone number **successfully found** - Failed lookups cost nothing **Limits:** - Max 500 people per request - People must belong to the authenticated user - People must have a LinkedIn URL for enrichment to work **Example request:** ```json { "people_ids": [101, 102, 103], "enrich_emails": true, "enrich_phones": false } ``` **Error codes:** - ``INVALID_REQUEST`` (400) — Empty people_ids or both enrich flags are false - ``PERSON_NOT_FOUND`` (404) — One or more people_ids not found or not owned by user

Poll the status of a people enrichment job. Returns the current status and, when completed, per-person results with emails and phone numbers found, plus credits consumed. **Status values:** - ``pending`` — Job created, not yet started - ``running`` — Enrichment in progress - ``completed`` — All done; check ``result`` for per-person data and ``credits_used`` for cost - ``failed`` — Job failed; check ``error_message`` **Polling recommendation:** Every 3-5 seconds. Typical enrichment takes ~2 seconds per person due to upstream API rate limiting (30 requests/minute). **Example response (completed):** ```json { "job_id": "abc-123", "status": "completed", "progress": {"total": 3, "completed": 3, "emails_found": 2, "phones_found": 0}, "credits_used": {"emails": 2, "phones": 0, "total": 2}, "result": [ {"person_id": 101, "email": "alice@company.com", "status": "enriched"}, {"person_id": 102, "email": "bob@company.com", "status": "enriched"}, {"person_id": 103, "email": null, "status": "not_found"} ] } ```

End-to-end company qualification and people enrichment. 1. Creates or finds the account for the given domain. 2. Finds intent signals for the company. 3. Enriches the account with people — finds relevant team members and ICP qualifies them. Requires either `icp_id` or `target_icp_roles`. Runs in background — use `account_id` to get latest account status. Deep enrichment can take 15-30 minutes to find intent signals and people.

Get people details by IDs (comma-separated).

Start a background job to verify people still work at their associated companies. Uses Fiber live-fetch API to confirm current employment. People confirmed as departed are removed along with all dependent records. Credits are charged per person found in the workspace.

Poll the status of a people verification job.

Start an async CRM sync job for accounts and their people. Creates a background job that syncs the specified accounts and all their people to the connected CRM (Salesforce or HubSpot). Returns a job_id immediately for status polling. **Flow:** 1. Call this endpoint -> get job_id 2. Poll `/check-job-status` with job_id until status is "completed" or "failed" 3. When completed, the result field contains detailed sync results **Behavior:** - Accounts already in CRM with the same owner are updated with latest signals - Accounts in CRM with a different owner are updated with new signals. Ownership stays unchanged. - New accounts are created in CRM - People already in CRM with the account having same owner are updated with latest signals - People already in CRM with the account having different owner are updated with new signals. Ownership stays unchanged. - New people in account having same owner are created with assigned user as the people owner. - New people in account having different owner are created with account owner as the people owner.

Start an async CRM sync job for people (and their parent accounts). Creates a background job that syncs the specified people to the connected CRM (Salesforce or HubSpot). Parent accounts are automatically resolved and synced first. Returns a job_id immediately for status polling. **Flow:** 1. Call this endpoint -> get job_id 2. Poll `/check-job-status` with job_id until status is "completed" or "failed" 3. When completed, the result field contains detailed sync results for both accounts and people **Behavior:** - Parent accounts are synced first - Accounts already in CRM with the same owner are updated with latest signals - Accounts in CRM with a different owner are updated with new signals. Ownership stays unchanged. - New accounts are created in CRM - People already in CRM with the account having same owner are updated with latest signals - People already in CRM with the account having different owner are updated with new signals. Ownership stays unchanged. - New people in account having same owner are created with assigned user as the people owner. - New people in account having different owner are created with account owner as the people owner.

Check the status of a CRM sync job. Returns the current status and, when completed, the full sync results. **Status values:** - `pending`: Job created, not yet started - `running`: Sync is in progress - `completed`: Sync finished - check `result` field for details - `failed`: Sync failed - check `error_message` for details **Polling recommendation:** Poll every 3-5 seconds.

**DEPRECATED — this endpoint no longer deploys signals and returns HTTP 410 Gone.** Deep Company Search has been replaced by the **Company Initiatives** and **People Hired** signal APIs. Migrate to one of: Company Initiatives: - Hiring for a Role — https://product-docs.openfunnel.dev/signal-deployment/hiring-for-role - Hiring for an Initiative — https://product-docs.openfunnel.dev/signal-deployment/hiring-for-initiative - Mentioning Concepts in Job Posts — https://product-docs.openfunnel.dev/signal-deployment/hiring-for-concepts - Multiple Job Posts for a Role — https://product-docs.openfunnel.dev/signal-deployment/hiring-spike-for-role - Multiple Job Posts Mentioning a Concept — https://product-docs.openfunnel.dev/signal-deployment/hiring-spike-for-concept - Surge in Hiring for a Role — https://product-docs.openfunnel.dev/signal-deployment/relative-hiring-spike-for-role - Surge in Mentions of a Concept — https://product-docs.openfunnel.dev/signal-deployment/relative-hiring-spike-for-concept - First-Time Hire for a Role — https://product-docs.openfunnel.dev/signal-deployment/first-hire-for-role - First-Time Mention of a Concept — https://product-docs.openfunnel.dev/signal-deployment/job-post-first-time-mention People Hired: - People Hired for Initiatives — https://product-docs.openfunnel.dev/signal-deployment/people-hired-for-initiatives - People Hired First Time — https://product-docs.openfunnel.dev/signal-deployment/people-hired-first-time

**DEPRECATED — this endpoint no longer deploys signals and returns HTTP 410 Gone.** Deep Hiring has been replaced by the **Company Initiatives** and **People Hired** signal APIs. Migrate to one of: Company Initiatives: - Hiring for a Role — https://product-docs.openfunnel.dev/signal-deployment/hiring-for-role - Hiring for an Initiative — https://product-docs.openfunnel.dev/signal-deployment/hiring-for-initiative - Mentioning Concepts in Job Posts — https://product-docs.openfunnel.dev/signal-deployment/hiring-for-concepts - Multiple Job Posts for a Role — https://product-docs.openfunnel.dev/signal-deployment/hiring-spike-for-role - Multiple Job Posts Mentioning a Concept — https://product-docs.openfunnel.dev/signal-deployment/hiring-spike-for-concept - Surge in Hiring for a Role — https://product-docs.openfunnel.dev/signal-deployment/relative-hiring-spike-for-role - Surge in Mentions of a Concept — https://product-docs.openfunnel.dev/signal-deployment/relative-hiring-spike-for-concept - First-Time Hire for a Role — https://product-docs.openfunnel.dev/signal-deployment/first-hire-for-role - First-Time Mention of a Concept — https://product-docs.openfunnel.dev/signal-deployment/job-post-first-time-mention People Hired: - People Hired for Initiatives — https://product-docs.openfunnel.dev/signal-deployment/people-hired-for-initiatives - People Hired First Time — https://product-docs.openfunnel.dev/signal-deployment/people-hired-first-time

Deploy a Social Listening signal. OpenFunnel Company Social Listening Agents listen for any announcements or conversations that a company is making across LinkedIn, Twitter, or Google. Listen on things like: - I want to target companies who raised seed funding - I want to target companies posting about attending RSAC conference - I want to target companies opening remote offices - I want to target companies adding AI to their existing stack

**DEPRECATED — this endpoint no longer deploys signals and returns HTTP 410 Gone.** Technography Search has been replaced by the four **Company Tech Stack** signal APIs. Migrate to one of: - Tech Stack — https://product-docs.openfunnel.dev/signal-deployment/tech-stack - Tech Stack Spike — https://product-docs.openfunnel.dev/signal-deployment/tech-stack-spike - Tech Stack First Mention — https://product-docs.openfunnel.dev/signal-deployment/tech-stack-first-mention - Tech Use Case — https://product-docs.openfunnel.dev/signal-deployment/tech-use-case

Deploy an ICP Job Change signal. Find newly joined people in your ICP at your target companies - new joinees come in with budgets, plans and ideas; it's an ideal time to outreach. OpenFunnel segregates new joinees from promotions so your outreach is relevant and not landing to the wrong people.

Deploy a Competitor Engagement signal. Find and qualify every ICP liking or commenting on posts by any LinkedIn profile.

Deploy a Competitor Activity signal. Monitor potential customers your competitors are engaging with. This competitor activity agent surfaces accounts and people that your competitors are actively reaching out to on LinkedIn.

Find companies actively posting job listings for a specific role. Use this when you want to discover companies that are hiring for a particular position — e.g. "Solutions Engineer", "VP of Sales", "Data Engineer". The signal scans recent job postings and surfaces companies with open roles matching your query, filtered against your ICP. **When to use:** You know the exact role title or function you're targeting. **Sentence:** [descriptive_icp] companies hiring for [role] Examples: - role="Solutions Engineer", descriptive_icp="B2B fintech" - role="VP of Sales", descriptive_icp="Vertical SaaS" - role="Data Engineer" (no descriptive_icp — searches across all industries)

Find companies with a specific strategic initiative, migration, or expansion. Use this when the user describes a business initiative rather than a role title — e.g. "ERP migration", "AI agent rollout", "expanding to APAC". **When to use:** The target is a company initiative, not a specific job title. **Sentence:** [descriptive_icp] companies having the initiative of [initiative] Examples: - initiative="ERP migration", descriptive_icp="Fortune 500" - initiative="AI agent rollout", descriptive_icp="B2B SaaS"

Find companies mentioning a specific concept or keyword in their job postings. Use this when the user wants to discover companies whose job posts reference a technology concept, methodology, or domain — e.g. "self hosted models", "zero trust architecture", "product-led growth". **When to use:** The target is a concept/keyword appearing in job descriptions. **Sentence:** [descriptive_icp] companies mentioning [concept] Examples: - concept="self hosted models", descriptive_icp="B2B SaaS" - concept="AI governance", descriptive_icp="Fortune 500"

Find companies with hiring spikes — a specific role appearing in multiple job posts. Use this when you want to detect companies that are aggressively hiring for the same role (e.g. 5+ "data engineer" posts in 90 days = scaling data team). **When to use:** You want volume/spike detection, not just any single job post. **Sentence:** [descriptive_icp] companies hiring for [role] in [count_threshold]+ posts in [window_days] days Examples: - role="data engineer", count_threshold=5, window_days=90, descriptive_icp="B2B fintech" - role="AI engineer", count_threshold=10, window_days=30, descriptive_icp="DevTools"

Find companies with concept spikes — a keyword/concept appearing in multiple job posts. Use this when you want to detect companies that are repeatedly mentioning a concept across their job postings (e.g. 3+ posts mentioning "kubernetes migration" in 90 days). **When to use:** You want volume/spike detection for a concept, not just any single mention. **Sentence:** [descriptive_icp] companies mentioning [term] in [count_threshold]+ posts in [window_days] days Examples: - term="kubernetes migration", count_threshold=3, window_days=90, descriptive_icp="B2B SaaS" - term="AI governance", count_threshold=5, window_days=30, descriptive_icp="Enterprise"

Find companies whose hiring for a role is *accelerating* — not just high volume. Unlike /hiring-spike-for-role (which qualifies on an absolute count in a window), this detects a ramp: it buckets matching job posts into three trailing 30-day windows and qualifies a company when the most-recent bucket grows by at least growth_pct_threshold versus the average of the prior two (a zero baseline with any recent posts also qualifies). **When to use:** You want companies that just *started ramping* hiring for a role, catching the inflection rather than steady-state volume. **Sentence:** [descriptive_icp] companies accelerating hiring for [role] Examples: - role="AI engineer", growth_pct_threshold=100, descriptive_icp="B2B SaaS" (doubling) - role="data engineer", growth_pct_threshold=50, descriptive_icp="DevTools"

Find companies whose job-post mentions of a concept are *accelerating* — not just frequent. Unlike /hiring-spike-for-concept (absolute count in a window), this detects a ramp: it buckets matching job posts into three trailing 30-day windows and qualifies a company when the most-recent bucket grows by at least growth_pct_threshold versus the average of the prior two (a zero baseline with any recent posts also qualifies). **When to use:** You want companies that just *started ramping* mentions of a concept, catching the inflection rather than steady-state volume. **Sentence:** [descriptive_icp] companies accelerating job posts mentioning [term] Examples: - term="kubernetes migration", growth_pct_threshold=100, descriptive_icp="B2B SaaS" - term="AI governance", growth_pct_threshold=50, descriptive_icp="Enterprise"

Find companies that mentioned a specific concept or keyword in their job postings for the very first time. Use this when you want to catch companies newly signaling interest in a concept — e.g. their first job post ever mentioning "ERP Migration" or "AI agents". **When to use:** You want first-time detection of a concept in job posts, not ongoing mentions. **Sentence:** [descriptive_icp] companies mentioning [term] for the first time in their job posts Examples: - term="ERP Migration", descriptive_icp="Fortune 500" - term="AI agents", descriptive_icp="B2B SaaS"

Find people who were recently hired to execute a specific job-to-be-done. Use this when you want to discover people who joined companies specifically to do something — e.g. "setup outbound sales", "lead AI transformation". **When to use:** The focus is on PEOPLE (not companies), hired for a purpose. **Sentence:** People hired to [job_to_be_done] at [descriptive_icp] companies Examples: - job_to_be_done="setup outbound sales", descriptive_icp="B2B fintech" - job_to_be_done="lead AI transformation", descriptive_icp="Fortune 500"

Find companies that posted a job for a specific role for the very first time. Scans job postings to detect when a company starts hiring for a role it has never posted before — e.g. their first-ever "Solutions Engineer" or "Head of AI" listing. This signals a new investment area or team build-out. Requires descriptive_icp or accounts for candidate discovery (icp_id alone is insufficient). **When to use:** You want to catch companies that just started posting for a new role. **Sentence:** [descriptive_icp] companies hiring for [role] for the first time Examples: - role="Solutions Engineer", descriptive_icp="B2B SaaS" - role="Head of AI", descriptive_icp="Fortune 500"

Find companies where someone was recently hired as the first person in a specific role. Uses people-index data to detect when a company brings on their very first hire for a role family — e.g. their first security engineer, first RevOps hire. This is different from /first-hire-for-role which detects first-time job postings. **When to use:** You want to find companies that actually hired someone new into a role for the first time. **Sentence:** [descriptive_icp] companies that made their first hire for [role] Examples: - role="Head of Security", descriptive_icp="B2B SaaS" - role="Revenue Operations", descriptive_icp="DevTools"

Find companies that match your ICP filters without requiring any activity signal. Use this when you want to build a target account list based purely on firmographic criteria (employee count, funding, location) and optionally an industry/type filter. **When to use:** No activity signal needed — just ICP matching or uploaded accounts. **Sentence:** Find [descriptive_icp] companies matching ICP Examples: - descriptive_icp="B2B fintech", icp_id=123 - accounts=[{website: "stripe.com"}, {website: "plaid.com"}] (uploaded list)

Surface people who recently changed jobs into companies matching your ICP. New joinees come in with budgets, plans, and ideas — it's an ideal time to outreach. Segregates new joinees from promotions. **When to use:** You want to catch people moving into new roles at target companies. **Sentence:** People who joined [descriptive_icp] companies Examples: - descriptive_icp="B2B fintech", icp_id=123 - descriptive_icp="Vertical SaaS"

Find companies running a specific technology in their stack. Searches job postings for mentions of the technology and qualifies companies. **When to use:** You know the exact technology name you're targeting. **Sentence:** [descriptive_icp] companies using [technography] Examples: - technography="Segment", descriptive_icp="B2B fintech" - technography="Snowflake", descriptive_icp="Vertical SaaS"

Find companies that mentioned a specific technology in their job postings for the very first time. Use this when you want to catch companies newly signaling interest in a technology — e.g. their first job post ever mentioning "Kubernetes" or "dbt". **When to use:** You want first-time detection of a tech stack, not ongoing usage. **Sentence:** [descriptive_icp] companies mentioning [technography] for the first time in their job posts Examples: - technography="Kubernetes", descriptive_icp="Fortune 500" - technography="dbt", descriptive_icp="B2B SaaS"

Find companies with technology adoption spikes — a tech appearing in multiple job posts. **When to use:** You want volume detection for a technology (not just one mention). **Sentence:** [descriptive_icp] companies mentioning [technography] in [count_threshold]+ posts in [timeframe] days Examples: - technography="Kubernetes", count_threshold=3, timeframe=90, descriptive_icp="B2B fintech" - technography="Snowflake", count_threshold=5, timeframe=180, descriptive_icp="DevTools"

Find companies using a specific technology for a particular purpose. Combines technology + use case for precision — e.g. "Snowflake for customer data platform" is more specific than just "Snowflake". **When to use:** You want companies using a tech for a SPECIFIC purpose, not just any usage. **Sentence:** [descriptive_icp] companies using [technography] for [use_case] Examples: - technography="Snowflake", use_case="customer data platform", descriptive_icp="B2B fintech" - technography="Datadog", use_case="observability rollout", descriptive_icp="DevTools"

Find companies mentioning a specific topic across social channels (LinkedIn, Twitter, Google). **When to use:** You want to discover companies talking about a topic publicly. **Sentence:** Companies mentioning [topic] on social Examples: - topic="AI governance" - topic="warehouse automation"

Find individual people discussing a topic across social platforms. **When to use:** You want to discover people (not companies) talking about a topic. **Sentence:** People mentioning [topic] on social Examples: - topic="AI agents" - topic="data residency"

Find and qualify ICP people who like or comment on posts by a specific LinkedIn profile. **When to use:** You want to find people in your ICP who engage with a known profile. **Sentence:** ICP people interacting with [linkedin_url] Examples: - linkedin_url="linkedin.com/in/founder-name"

Monitor a competitor or salesperson's LinkedIn activity to find accounts they're targeting. Surfaces accounts and people that the monitored profile is actively reaching out to. **When to use:** You want to see who a competitor salesperson is engaging with. **Sentence:** [linkedin_url] interactions with ICP people Examples: - linkedin_url="linkedin.com/in/competitor-ae"

Return the static list of ISO 3166-1 alpha-3 codes accepted by the Agent Primitive search endpoints (`/api/v1/account/search-lookalikes` `locations` and `/api/v2/tech/companies` `hq_country_code`), paired with a canonical English name. Ordered by company-data volume so the most useful values come first. Static, fast, no auth — intended as a one-shot discovery call so agents can validate or surface country options without trial-and-error.

Page through companies whose recent job posts mention a technology. Backed by a server-side OpenSearch `terms` aggregation on `company_slug` plus a `bucket_sort` pipeline aggregation that slices the requested page out of the ranked pool — one OS round-trip per page. With `enrich=true` (or when any firmographic filter is set), batches a ClickHouse lookup on the page's slugs and returns hits hydrated with firmographics. Read-only: no signals, no credits, no campaigns, no CRM. For the full bundled workflow use `/api/v2/signal/deploy/tech-stack` instead.

Start an async tech + activity-intent search. Finds companies whose recent job posts mention `tech`, then LLM-verifies each company's most recent matching posting against `activity`, early- stopping once `limit` companies qualify. Returns a ``job_id`` immediately; poll ``GET /api/v2/tech/companies/intent-search/{job_id}`` for status and to page through results. Read-only: no signals, no accounts, no campaigns, no CRM. Credits are pre-checked against `limit` here, then charged on the actual qualified count when the job completes.

Combined status + results for a tech intent-search job. Returns the job status, manifest, and one page of results in a single call. Check ``status`` for completion (``completed``/``failed``) — NOT ``next_cursor == null``, since a still-``running`` job can have a null ``next_cursor`` simply because pages haven't been written yet.

Answer one or two natural-language research questions about a company. Provide a `domain` plus at least one of `activity_question` (hiring / job-posting intent) or `qualifier_question` (people / org composition). Both stages run in parallel when both are present. Each stage returns: - a natural-language answer suitable for inline display, - a boolean verdict, - structured source evidence (job postings or LinkedIn profiles). The endpoint is read-only — no accounts, signals, audiences, or background enrichment jobs are created. Credits are charged once per successful call (background-recorded after the response is sent).

Start an async TAM build. Returns a ``job_id`` immediately; poll ``GET /api/v1/tam/build/{job_id}`` for status + paged results. Charges per unique company (incrementally, per band) as the build progresses.

Combined status + manifest + live progress + one page of the TAM master set.

Request cancellation (terminal). For a running/pausing job, flips to a transient ``cancelling`` state and the worker stops at its next checkpoint; for an already ``paused`` job (no running worker), settles it to ``cancelled`` directly. Either way the delivered pages stay readable and only the delivered count was charged. Already-terminal jobs return 409.

Request a pause. Flips the job to a transient ``pausing`` state; the worker finishes the in-flight band (writing + checkpointing it) and then settles to ``paused`` — resumable via ``POST /api/v1/tam/build/{job_id}/resume``. Idempotent for an already-pausing/paused job; terminal/cancelling jobs return 409.

Resume a ``paused`` build from its checkpoint. Continues from the next ICP band, rebuilding the dedup set from the already-delivered blob pages (so completed bands are neither re-delivered nor re-charged). Only a ``paused`` job can resume; a guarded ``paused -> running`` transition rejects a double-resume with 409.

List all user-facing verticals available for event exploration.

List event types within a vertical, including account and people counts.

Find accounts in a vertical using slim, paginated results.

Search accounts by name or domain inside a vertical and embed latest events for each match.

Find people in a vertical using slim, paginated results.

Get a slim account object plus related people and events for one vertical.

Get paginated event instances for an account within one vertical.

Get paginated event instances for a person within one vertical.