> ## Documentation Index > Fetch the complete documentation index at: https://deepline.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Use CrustData V3 in Deepline > Use free autocomplete first, then cheap indexed search, then enrich selected records. Treat name-only company identify results as unverified. [Human guide: work with your agent →](https://deepline.com/docs/human/providers/crustdata-v3/guide.md) Inspect one CrustData V3 action before starting provider-backed work. Your first result is a verified input and output contract. ## Provider-specific requirements Use autocomplete before search when filter values are uncertain. Autocomplete is free and reduces expensive zero-result searches. Use indexed search for discovery: * `crustdata_v3_person_search` * `crustdata_v3_company_search` * `crustdata_v3_job_search` Keep `limit` strict. Search is billed per returned result, not by matched `total_count`. Filter to people with verified work emails before paying for enrichment. Person search accepts `experience.employment_details.current.business_email_verified` as a filter field (`type: "="`, `value: true`) — it selects only people whose current employment carries a verified business email, so every returned result is enrichable to a valid work email. The flag is a boolean, not the address: the emails themselves come back from person enrich under `contact.business_emails[*].email`, each with a `status` field (`verified` / `unverified`). Never read the profile-level email field or `contact.personal_emails` when the goal is work emails. ### Filter syntax and operators Person/company/job search all take a `filters` condition group: `{"op": "and", "conditions": [{"field": "...", "type": "=", "value": ...}]}` - groups nest, and `op` accepts `and` / `or`. Condition `type` supports `=`, `!=`, `in`, `not_in`, `contains`, `has_all`, `all_of`, `>`, `<`, `=>`, `=<`. Sorting is `sorts: [{"field": "...", "order": "asc" | "desc"}]`. Company and job search have their own filter/sort field vocabularies - read the field lists in each tool's input schema (`deepline describe`) rather than reusing person fields. ### Company-search response projections For `crustdata_v3_company_search`, `filters` and `fields` are different vocabularies. A field path that can filter companies is not necessarily a response selector. Request response groups such as `basic_info`, `headcount`, `funding`, `locations`, and `taxonomy`, then read nested values from the returned group. Do not request `basic_info.industries` or period leaves such as `headcount.growth_percent.6m`. Use `basic_info` and `headcount.growth_percent` respectively. `roles`, `skills`, `seo`, and `competitors` are filter-only for this endpoint. ### Size and qualify for free before paying * `limit: 1` returns `total_count` and `total_count_relation` - TAM sizing for the price of one result. * `preview: true` (person search and person enrich) returns basic fields at preview billing - confirm identity/shape before buying full records. * Person search results include `contact.has_business_email`, `has_personal_email`, and `has_phone_number` booleans - you can see contact availability per person before spending on enrichment. * `fields: [...]` on search and enrich limits the returned field paths. on enrich, requested field groups drive the price - request only what the workflow uses. ### High-leverage person filters most workflows miss * **Job changes**: `recently_changed_jobs` filters to people who recently switched roles. pair with `metadata.updated_at` (range operators) to bound data freshness. * **Alumni prospecting**: the `experience.employment_details.past.*` family (`past.company_name`, `past.company_id`, `past.company_linkedin_profile_url`, `past.company_headcount_range`, `past.company_industries`) finds everyone who USED to work somewhere - "ex-Stripe, now at a 11-200 person company" is two conditions. * **Open to work**: `professional_network.open_to_cards` (values like `CAREER_INTEREST`, `HIRING_MANAGER`) surfaces people signalling openness. * **Normalized titles**: prefer `basic_profile.normalized_title.matched_title`, `.department`, and `.sub_department` over raw title string matching - it is CrustData's normalized taxonomy and beats regex title lists. * **Employer size without a company join**: `experience.employment_details.current.company_headcount_range` / `company_headcount_latest` filter people by their employer's size directly. * **Seniority and function**: `experience.employment_details.current.seniority_level` and `.function_category` are the org-chart building blocks. * **Influence and tenure**: `professional_network.connections`, `.followers`, and `years_of_experience` support scoring and champion selection. Use enrich after narrowing candidates: * `crustdata_v3_person_enrich` for full cached person profiles. * `crustdata_v3_person_contact_enrich` for contact-only lookups. * `crustdata_v3_company_enrich` for full company records. * `crustdata_v3_dev_platform_enrich` for a person's linked GitHub profile. * `crustdata_v3_social_post_search` for what a person or company is posting about. ### Developer signals (GitHub, posts, technographics) Person search can select developers by their GitHub footprint, but it never returns that data: `dev_platform_profiles.*` fields are filter-only (`fields: ["dev_platform_profiles"]` on search is a 400). Filter, then enrich. * **Find developers at target accounts**: `crustdata_v3_person_search` with `experience.employment_details.current.company_website_domain` (`in`, at most 5 domains per search) plus `dev_platform_profiles.public_repo_count` (`=>`), `dev_platform_profiles.total_stars`, `dev_platform_profiles.all_languages` (`has_all`), or `dev_platform_profiles.repos.topics`. Add `social_handles.twitter_handle` `is_not_null`-style conditions only when the operator is documented for the field. * **Read the GitHub profile**: `crustdata_v3_dev_platform_enrich` with `profile_url` (a GitHub profile URL) or `crustdata_person_id` from search, enrich, or a social post's `actor.crustdata_entity_id`. It returns repos with stars and languages, totals, followers, topics, `declared_handles` (LinkedIn, website), org memberships, and metric history for 1 credit. A 404 means no linked account and is free. A LinkedIn URL is rejected. For a batch of LinkedIn URLs, `crustdata_v3_person_enrich` with `fields: ["social_handles", "dev_platform_profiles"]` returns the same profile object for 2 credits per matched person, 25 URLs per call, and also the X handle under `social_handles.twitter_identifier.slug`. * **What they talk about**: `crustdata_v3_social_post_search` filtered on `actor.professional_network_url` (one person) or `actor.company_name` plus a `text` `[.]` phrase (a topic across a company). Use `limit: 0` first. It returns `total_count` for free. Every returned post costs 0.5 credits, so keep `limit` small and leave `reactors` and `comments` out of `fields`. `crustdata_v3_person_enrich` with `fields: ["social_posts"]` returns up to the 10 most recent posts for 5 extra credits and is permission-gated. * **Company tech stack**: `crustdata_v3_company_enrich` with `fields: ["basic_info", "technographics"]` returns `technographics` (`total_technologies`, `top_technologies`, `technologies[]` with `sources`, `posting_count`, `categories`, `evidence`). It costs 2 extra credits only for companies that return data and is gated per account (403 `Access denied to fields: technographics` without the grant). Company search filters on `technographics.technologies.name`, `.category`, `.super_category` (for example `engineering-devops`), and `technographics.top_technologies`. A GitHub handle alone is not a resolved person. Accept a GitHub-to-LinkedIn link only when `declared_handles` carries the LinkedIn URL, or when the Crustdata person id came from a LinkedIn-anchored enrich. name-only agreement stays a candidate. Use `crustdata_v3_company_identify` before company enrich when the inbound identifier is fuzzy. It is free. Prefer a domain or LinkedIn company URL. Name-only matching can return unrelated companies even at `confidence_score: 1.0`. treat those results as candidates and verify an independent identifier before changing stored names or domains. Some `crustdata_v3_person_enrich` field groups require additional account entitlements. For example, requesting `certifications` can return HTTP 403. The schema permits fields that some accounts cannot access. If a field group causes `PROVIDER_AUTHORIZATION_FAILED`, omit that group and retry. Do not assume every account can access every documented group. Do not use old PersonDB field paths with V3 unless a reviewed compatibility mapper converts them to the documented `2025-11-01` field vocabulary. ## Find an applicable action Confirm your effective workspace, then search the live catalog: ```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}} deepline auth status --json deepline search "CrustData V3" --type tools --json ``` Search returns candidates. Check the returned provider and operation rather than selecting a similar title automatically. ## Inspect the selected contract Replace `` with the identifier returned by discovery: ```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}} deepline describe --json ``` These commands do not execute the selected provider action. Read its required inputs, supported access mode, pricing unit, outputs, and limits. A connection does not establish that every action supports BYOK. Follow the provider-specific requirements above and the live action contract. ## Prepare one reviewed input Use one authorized record that matches the inspected schema. Preserve its source identity and define the result you will accept. Open the action reference for its payload and response shape. Provider-backed execution can incur usage or external effects. For reusable logic, follow [Write Plays](https://deepline.com/docs/sdk-v2/plays.md). For direct-call recovery, use [Tool execution recovery](https://deepline.com/docs/sdk-v2/tool-execution-recovery.md). > [!TIP] > > Continue only when the workspace, provider, required fields, acceptance rule, and applicable price are understood. Keep unavailable access separate from no-result evidence. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.