Yes, a team can use the Crunchbase API, but access is a paid, customized offering for approved developers and licensees. Do not assume that a free account or a Pro web-app subscription includes API credentials. The API is a read-only REST service, and the fields and endpoints available to your integration depend on the licensed package.
A reliable implementation starts before the first API request. Resolve a company name to the correct organization UUID, request only licensed fields and cards, preserve the observation context, and validate the destination write. The API can support enrichment, research, and prioritization, but it does not remove the need for identity rules, licensing checks, or operational ownership.
Crunchbase currently documents three API package groups: Fundamentals, Insights, and Predictions. Insights and Predictions include Fundamentals, while endpoint and field access depends on the license associated with the API key. Confirm package scope, volume, data-use rights, and destination behavior with Crunchbase before building.
What the Crunchbase API provides and who can access it
Fundamentals provides the base company and relationship data layer. Insights adds capabilities such as growth, investors, competitors and similarity, market activity, valuation estimates, and comparables. Predictions covers documented outcomes including funding, acquisition, IPO, closure, growth, layoffs, and remaining private.
These categories do not mean that every account receives the same response structure. The Crunchbase API package overview describes the package model, while the Data Dictionary explains fields. A field appearing in the dictionary is not proof that it is enabled for your API key.
Crunchbase support describes API pricing as customized according to use case, volume, and licensed data type. Current support material does not establish one universal public API price or one plan name as the only access route. Treat a web-app subscription and an API license as separate questions, then confirm the terms for the account that will make the requests. The Crunchbase API FAQ and the account and subscription comparison provide useful context.
Treat API access as a licensed data contract first and a technical connection second. The package, permitted fields, destinations, and reuse rights determine what the integration may safely do.
Resolve a company before requesting its record
A company name is a label, not a unique key. Crunchbase autocomplete produces candidate entities, but it does not guarantee an exact match. Compare candidate names, descriptions, collection types, and identifiers before choosing an organization. Then use the selected UUID or permalink for entity lookup and request only the permitted field_ids and card_ids.
The autocomplete examples, entity lookup reference, and data-model guide document these patterns. If two candidates remain plausible, stop enrichment and send the record to a data steward or CRM operations owner.
The following is an illustrative internal review record, not a Crunchbase response schema:
{
"input_name": "Acme",
"candidate_uuid": "illustrative-uuid",
"candidate_name": "Acme Example Ltd.",
"candidate_collection": "organization",
"candidate_permalink": "acme-example",
"match_reason": "Country and company description match",
"review_required": true,
"resolved_at": null
}Keep omitted fields, explicit null values, numeric zero, and empty arrays distinct. An omitted or unlicensed field is not the same as a known zero, and an empty relationship is not necessarily the same as an unrequested relationship. Relationship cards may require pagination, so do not assume that one response contains every related record.
Choose a package and interpret predictions correctly
Fundamentals is the base layer. Insights provides additional analytical capabilities, while Predictions provides documented prediction outcomes. Exact response fields and access depend on the licensed endpoints. Consult the Insights documentation, Predictions documentation, and your package-specific reference rather than assuming that one endpoint returns every capability.
For Predictions, probability_score is a value from 0 to 1, and generated_on identifies the prediction observation context. Some prediction types expose timing intervals and others do not. The overall score has no fixed prediction horizon. Where timing data is provided, the values describe interval probabilities relative to generated_on; do not add them together to recreate the overall score.
A score of 0.8 is not automatically an 80% chance of an event within the next six months. Preserve generated_on, read only the timing intervals documented for that prediction type, and apply a freshness and business rule before routing. Never let the score alone trigger outreach.
Do not publish a universal prediction-accuracy percentage without a current, citable methodology from Crunchbase. The available documentation supports interpretation of the score and timing fields, not a blanket accuracy claim.
For prioritization, store one raw observation per organization, prediction type, and generated prediction record or date. Retain retrieval time, applicable timing data, package context, and the raw response or an immutable hash. This lets an analyst distinguish a new observation from a repeat retrieval and assess whether a score is stale before acting.
Design ingestion to survive retries and duplicates
Choose a record grain before creating tables or CRM fields. A company profile is one current record per organization UUID. A funding round is a separate record identified by its own source identifier where available. A prediction observation is one organization, prediction type, and generated observation. An ingestion run and a destination write attempt are operational records, not company events.
The following is a proposed internal schema, not a Crunchbase-published schema. Each row represents one prediction observation. The generated date belongs to the observation grain, while retrieval time describes when your system obtained it.
{
"source_system": "crunchbase",
"organization_uuid": "illustrative-uuid",
"prediction_type": "funding",
"generated_on": "2026-10-01",
"retrieved_at": "2026-10-02T09:15:00Z",
"probability_score": 0.72,
"time_window": null,
"raw_response_hash": "illustrative-sha256",
"api_package": "licensed-package-name",
"review_status": "pending"
}A candidate uniqueness key is source_system + organization_uuid + prediction_type + generated_on + prediction_record_id, when a source record ID exists. If the API does not provide one, define a data contract that distinguishes separate observations and document how model or record revisions are handled. Do not use a daily date alone if multiple records can occur on that date.
Enforce the chosen key with a database uniqueness constraint and use a transactional upsert or insert-on-conflict operation. A read-then-create sequence can race when concurrent workers process the same company. A search step in an automation tool is useful for routing, but it is not a database uniqueness guarantee.
Retain source identifiers, retrieval time, generated date, requested fields, transformation version, review status, destination record ID, write result, and error details. For CRM updates, decide which system owns company identity and duplicate resolution. Do not send a consequential field change until identity, freshness, and update rules pass validation. Teams formalizing ownership and writeback rules may find the CRM systems service relevant.
Use API calls, Zapier polling, or MCP for the right job
These access paths solve different operational problems. The following comparison separates documented platform behavior from proposed implementation decisions.
| Trigger | Proposed AI job | Validation and action | Fallback |
|---|---|---|---|
| Licensed API request | Optional evidence summary for a known UUID | Check package access, required fields, pagination, freshness, and database key before upsert. | Retry transient failures with preserved pagination state; route missing identifiers to data operations. |
| Zapier New List or New Company in Saved Search polling | Optional queue summary or classification using returned evidence | Verify the connected account’s trigger, fields, and destination action in the Zap editor before a write. | Stage the event and assign duplicate or CRM conflicts to the automation or CRM owner. |
| User-authenticated MCP research | Search, retrieve, and summarize evidence for identified organizations | Confirm account access, data-token allowance, source fields, and human review before CRM writeback. | Save a research note or review task rather than making an unattended update. |
Direct API. Current documentation shows HTTPS requests authenticated with the X-cb-user-key header. Keep keys out of URLs, store them in a secrets manager, and rotate them under an assigned owner. Crunchbase documents a limit of 200 calls per minute. Treat that as a ceiling, not a sustained target. Pace requests below the limit, handle transient errors, and retain pagination state so a retry does not silently skip or repeat pages. See the Crunchbase API usage documentation.
Zapier. The current Crunchbase integration directory lists polling triggers for “New List” and “New Company in Saved Search,” alongside example destination applications. A polling trigger is not evidence of a native Crunchbase webhook. Confirm the trigger, available fields, and destination actions in the connected account’s Zap editor. Search, create, update, deduplication, retries, validation, and approval must be configured and tested for the specific workflow.
A proposed staging chain is: Crunchbase polling trigger, staging table, UUID and required-field checks, CRM search or update action if verified in the editor, then a write-result log. If a company name maps to multiple CRM records, stop the write and assign the conflict to CRM operations. The Zapier automation design service is relevant to defining that workflow and its exception ownership.
MCP. Crunchbase documents an MCP connection for supported AI clients, including OAuth 2.1, account or workspace access, and data-token allowances. Availability depends on account access, workspace entitlements, seats, and allowances. MCP allowances are distinct from API quota, and MCP is not automatically an unattended backend integration. Use it for bounded, user-authenticated research unless the account and implementation terms explicitly support the intended programmatic use. Require a person to approve CRM-facing changes. The MCP getting-started guide, developer reference, and access-management guidance explain current setup considerations. Teams defining bounded AI research and review paths can also explore AI agent services.
Access, keys, pricing, and licensing checks
Crunchbase support directs API customers to Integrations settings, while key visibility depends on account and team permissions. Team owners may have access to team package keys. Send the key in the request header and restrict storage and use to the approved integration.
- The licensed package, permitted fields, cards, and endpoints for the use case.
- Expected call volume, pagination needs, and the applicable usage limit.
- The key owner, access permissions, storage method, and rotation process.
- MCP access, supported client, workspace entitlement, and data-token allowance if MCP is included.
- Intended storage and destination systems, including any customer-facing use.
- Attribution, retention, storage, and redistribution terms in the applicable agreement.
Current package names, commercial terms, entitlements, and included features can change. Confirm the written scope with Crunchbase before purchase or implementation. Treat licensing as a design requirement when data moves into a product, CRM, or customer-facing workflow.
When EDGAR or another data source may fit better
Choose a source based on the evidence you need. SEC EDGAR is useful when you need primary filing evidence for a filing that exists, including certain private offerings such as Form D records. Its public APIs provide submissions history and extracted XBRL data without API keys. Automated clients must identify themselves with a User-Agent and follow SEC access policies. EDGAR is not a complete normalized private-company database, and coverage depends on filing obligations. See the SEC EDGAR API documentation.
- Need normalized company and investor relationships: evaluate Crunchbase or another licensed structured dataset by field coverage, freshness, entity resolution, and usage rights.
- Need evidence in a filing: use EDGAR where the relevant filing is available, then budget for finding and interpreting the document.
- Need broad web extraction: assess a platform such as Apify only if the team can own parsing, identity resolution, monitoring, and compliance review. Verify current pricing and terms directly.
- Considering another commercial dataset: evaluate candidates such as Crustdata against current coverage, API access, licensing, and pricing rather than assuming equivalence.
A practical decision before building
Start with the data need and written license scope. Test entity resolution on ambiguous names, define the record grain and database-enforced key, then choose direct API, verified Zapier polling, or user-authenticated MCP research. Specify field validation, freshness rules, write permissions, and ownership for unresolved matches and failed writes before any CRM automation runs.
Use deterministic rules for clear requirements such as “UUID must be present,” “generated date must be within the freshness limit,” and “this value must be in the allowed list.” AI can summarize evidence or classify a review queue, but it should not silently resolve ambiguous identity or make an unreviewed CRM change.
Measure coverage, freshness, duplicate rate, failed writes, stale observations, and review backlog. Those measures show whether the workflow is reliable in operation. The API can provide valuable data, but dependable outcomes come from the surrounding controls.