Skip to main content
Human guide: work with your agent → 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:
Search returns candidates. Check the returned provider and operation rather than selecting a similar title automatically.

​
Inspect the selected contract

Replace <returned-tool-id> with the identifier returned by discovery:
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. For direct-call recovery, use Tool execution recovery.
Continue only when the workspace, provider, required fields, acceptance rule, and applicable price are understood. Keep unavailable access separate from no-result evidence.