Action and system primitives
Primitive 1: the decision the data needs to support
A data enrichment API is only useful when the extra fields change a real GTM decision. Before you run enrichment, write down the job in plain English:
| GTM job | Fields to enrich | Decision it unlocks |
|---|---|---|
| Prioritize inbound leads | work email, title, company size, country | route high-fit leads before low-fit leads |
| Build an outbound list | email, phone, LinkedIn URL, role | decide who is safe to contact |
| Refresh stale CRM accounts | domain, industry, employee range, status | decide which accounts need human review |
| Score existing customers | company profile, lifecycle stage, region | decide which accounts enter expansion plays |
That framing keeps the workflow grounded. The goal is not "enrich everything." The goal is to add the few fields your next step actually needs.
Primitive 2: the prompt that turns a CSV into a plan
Give the Deepline skill a short planning prompt before asking it to run anything:
You are helping me enrich a GTM CSV.
Input file: leads.csv
Business goal: prepare this list for outbound routing.
Required output columns: email, email_status, company_domain, title, company_size.
Inspect the CSV headers first. Map each required output field to the best available input columns.
If a required input is missing, stop and tell me what column is missing.
Run only a small sample first. After the sample, summarize match quality, missing fields, and whether the output is ready for the full file.
This gives the human a review point before credits, provider calls, or downstream CRM writes.
Primitive 3: reviewable output
For a CSV with first_name, last_name, company, and domain, the enriched file should add stable columns that another workflow can understand:
| first_name | last_name | domain | email_status | company_size | |
|---|---|---|---|---|---|
| Ada | Lovelace | example.com | ada@example.com | verified | 51-200 |
| Grace | Hopper | example.org | not_found | 1001-5000 |
The empty value is not a failure by itself. It becomes useful when the workflow also returns a status column, so the next step knows whether to retry, skip, or send the row to review.
How the primitives move through skills, scripts, and Workflows
Start with the skill. In Deepline, skills are the primary way to ask for data, shape the request, inspect sample output, and tighten the acceptance criteria before you automate anything.
Once the skill returns data you trust, promote the same field contract in one of two ways:
- use a script when the motion belongs in a repo, a local operator run, or a repeatable batch job,
- use a Deepline Workflow when the motion needs scheduling, production handoffs, review queues, or a durable operational record.
Scripts and Workflows use these surfaces underneath:
POST /api/v2/enrich/compilePOST /api/v2/plays/checkPOST /api/v2/plays/run
POST /api/v2/enrich/compile validates and normalizes enrichment arguments into an enrich config. This is the bridge between enrichment-shaped input and the CLI/SDK workflow that prepares Deepline play execution.
The CLI/SDK then turns that enrich config into play source and artifacts before calling POST /api/v2/plays/check. Use check as the preflight step when the skill-approved plan has been promoted into a script or Workflow.
POST /api/v2/plays/run executes the checked workflow after the CLI/SDK has prepared the play input. Scripts and Workflows can then watch run status through the play execution surfaces used elsewhere in Deepline.
The important point for a GTM operator is simple: the skill proves the data is useful first. Scripts and Workflows come after the sample is accepted.
Script pattern after the skill works
After the skill produces a sample you trust, deepline enrich can turn the same field contract into a repeatable script. It takes a CSV, maps fields, and writes a new CSV.
deepline enrich --input leads.csv \
--with '{"alias":"email","tool":"leadmagic_email_finder","payload":{"first_name":"{{first_name}}","last_name":"{{last_name}}","domain":"{{domain}}"}}' \
--output enriched-leads.csv
For prebuilt waterfall enrichment, use the play-backed waterfall alias inside the same JSON object spec:
deepline enrich --input leads.csv \
--with '{"alias":"email","tool":"name_and_domain_to_email_waterfall","payload":{"first_name":"{{first_name}}","last_name":"{{last_name}}","domain":"{{domain}}"}}' \
--output enriched-leads.csv
The important detail is that --with expects a JSON object with alias, tool, and payload. Treat waterfall aliases as composed play-backed flows, not atomic provider operations. For customer-facing scripts, run them through enrich or V2 play surfaces.
Quality check before deploying a Workflow
No workflow-specific enrich test route was found in the documented endpoint map. In the CLI/SDK-backed workflow, POST /api/v2/plays/check validates the play artifacts created from the enrich config before execution.
Use the skill and check step before full runs, then inspect a small sample manually. Ask:
- Did the workflow add the promised columns?
- Are missing values labeled clearly?
- Are the aliases stable enough for the next workflow?
- Does the result support the GTM decision you wrote at the top?
Cost and billing behavior
Keep pricing language Deepline-facing and workflow-oriented. In BYOK mode, you bring your own data-provider keys and Deepline does not add a platform fee for that mode. In managed mode, Deepline uses credit-based operation billing.
For waterfall enrichment, misses and matches depend on the mode and the providers tried. Single-provider enrichment commonly leaves coverage gaps. Waterfall enrichment improves match rates by querying multiple providers in sequence, but the lift varies by ICP and region.
The practical operating rule is simple: run a small checked sample first, inspect the output columns, and scale once the workflow is returning the fields your GTM system needs.