Action and system primitives
Primitive 1: the job, not the vendor logo
B2B data vendors are not interchangeable. One may be strong for company search, another for work emails, another for technology signals. The practical move is to compare vendors against the GTM job you need to run.
| GTM job | What to compare | Human decision |
|---|---|---|
| Build account lists | company filters, domains, firmographics | which accounts enter the list |
| Enrich contacts | email, phone, title, LinkedIn | which contacts are usable |
| Score accounts | fit fields, intent, tech stack | which accounts get prioritized |
| Refresh CRM records | freshness, missing fields, status | which records are safe to update |
Avoid broad claims like "best B2B data provider" unless the page names the job, input, output, and sample result.
Primitive 2: the vendor-evaluation prompt
You are helping me compare B2B data vendors for one GTM workflow.
Workflow goal: build a target-account list.
Required fields: company_name, domain, industry, employee_range, country, source_status.
Input criteria: B2B SaaS companies in the United States with 51-500 employees.
Find the relevant Deepline provider tools.
Describe the schema before execution.
Run a small sample only.
Report which fields came back consistently, which fields were missing, and whether the output is usable for routing or scoring.
This keeps the comparison grounded in real fields instead of vendor marketing language.
Primitive 3: comparable vendor output
| company_name | domain | employee_range | country | source_status | next_step |
|---|---|---|---|---|---|
| Example Co | example.com | 51-200 | US | matched | score |
| Sample Inc | sample.com | US | partial | review |
The missing employee range matters. If that field drives territory routing, the row should not silently pass.
How the primitives move through skills, scripts, and Workflows
Start with the Deepline skill. The skill is the primary way to compare vendor output, inspect sample records, and decide which provider is useful for the GTM job.
When the sample is accepted, promote that vendor choice and field contract into a script for repeatable batches or a Deepline Workflow for production scoring, routing, and review.
Company-search provider actions use:
POST /api/v2/integrations/{toolId}/execute
The {toolId} must be a real provider tool id. Confirmed company-search ids include free_simple_company_search, apollo_company_search, peopledatalabs_company_search, leadmagic_company_search, crustdata_v2_company_search_realtime, findymail_search_lookalike_companies, prospeo_search_company, and theirstack_company_search.
This gives scripts and Workflows a single execution shape for many data vendors while preserving the selected provider action. It also keeps vendor-backed work distinct from composed waterfall flows, which should run through enrich or plays when you need fallback logic.
Script pattern after the skill works
Use deepline tools execute only after the skill has helped select and validate a provider tool id:
deepline tools execute free_simple_company_search \
--input '{"sql":"SELECT * FROM companies LIMIT 5"}'
For a provider-backed company search, replace the tool id and payload with the provider action and fields returned by deepline tools describe:
deepline tools describe theirstack_company_search --json
deepline tools execute theirstack_company_search \
--input '{"company_keyword_slug_or":["snowflake"],"limit":5}'
Use discovery before execution when the skill is comparing b2b data companies:
deepline tools search company --json
Quality check before deploying a Workflow
For company search, POST /api/v2/integrations/test proxies free_simple_company_search through the real execute path. That is the documented safe validation path for the free company search workflow.
For provider-backed vendor workflows, no no-spend workflow-specific test route is currently documented. Do not present a paid provider-backed integrations/test case as safe validation unless the endpoint map explicitly confirms that behavior for the workflow.
Before using a vendor in production, run the same sample through the workflow that will consume the data. A provider is only "good" if its output supports your scoring, routing, or outbound decision.
Cost and billing behavior
Keep billing language Deepline-facing. In BYOK mode, customers bring their own data-provider keys and Deepline does not add a platform fee for that mode. In managed mode, Deepline uses credit-based operation billing.
Different data vendors return different field shapes and coverage patterns. Run a small sample first, inspect the account fields and failure cases, then scale only after the workflow returns records your scoring, routing, or outbound system can use.