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 to use the skill before writing scripts
Start with the Deepline skill. The skill is the primary way to turn "I have this file and I need these usable fields" into a tested data path. Give it the input you have, the output you want, and one example of what a good row should look like.
The skill should run a small sample, show good and bad rows, and tighten the acceptance criteria before you automate anything. Once the sample is accepted, 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 production Plays use these surfaces underneath:
POST /api/v2/plays/checkPOST /api/v2/plays/run
POST /api/v2/plays/check validates the complete Play module graph before execution. Use it when the skill-approved plan has been promoted into owned source.
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, run the same checked Play as a repeatable script. The run persists its rows in Runtime Sheets and prints the next inspection and export commands.
PLAY_NAME=$(deepline plays search "verified work email waterfall" --json | jq -er 'first(.plays[] | select(.inputSchema.properties.csv? != null) | (.reference // .name))')
deepline plays describe "$PLAY_NAME" --json
deepline plays run "$PLAY_NAME" --csv leads.csv --watch
For the maintained batch waterfall, the direct reference is also available:
deepline plays describe prebuilt/name-and-domain-to-email-waterfall-batch --json
deepline plays run prebuilt/name-and-domain-to-email-waterfall-batch --csv leads.csv --watch
The important detail is that Play inputs come from the described contract. Pass
structured JSON with --input or a dataset with --csv; do not reconstruct the
workflow as inline provider flags.
Quality check before deploying a Workflow
No workflow-specific no-spend provider test route is documented. POST /api/v2/plays/check validates the Play source and artifacts without executing provider calls.
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.