API essentials

Build applications and integrate Crunchbase data into your workflows with the REST API. The Crunchbase API is a read-only RESTful service for approved developers.

See the API Reference for endpoint details and example responses.

Accessing the REST API

API access is available through the Crunchbase sales team. If you already have access, retrieve your provisioned key from Crunchbase API integrations and select Show Key. If you cannot locate it, contact [email protected].

Your key grants access to your licensed fields and collections. See API Packages Overview for the package-to-reference mapping. Crunchbase Basic licensees should use Using the Basic API.

For a guided walkthrough, start with Make your first API request.

Authentication

Include your API key with every request. The recommended method is the X-cb-user-key request header:

GET /v4/data/entities/organizations/crunchbase HTTP/1.1
Host: api.crunchbase.com
X-cb-user-key: INSERT_YOUR_API_KEY_HERE
Accept: application/json

The equivalent cURL request is:

curl --request GET 'https://api.crunchbase.com/v4/data/entities/organizations/crunchbase' \
  --header 'X-cb-user-key: INSERT_YOUR_API_KEY_HERE' \
  --header 'Accept: application/json'

The API also accepts the user_key query parameter:

https://api.crunchbase.com/v4/data/entities/organizations/crunchbase?user_key=INSERT_YOUR_API_KEY_HERE

Prefer the header method because URLs can appear in browser history, logs, and monitoring systems. Keep API keys out of source control and redact them from logs and support messages.

Your API key identifies your access and is used to enforce applicable limits and quotas. Missing or invalid credentials, exceeded limits, and exhausted quotas can result in errors.

HTTPS and API base URL

All API requests require HTTPS. Requests without HTTPS return HTTP 426 Upgrade Required.

The API base URL is:

https://api.crunchbase.com/v4/data/

Request limits and retries

Each Crunchbase Enterprise API key has two independent limits:

You can reach the concurrency limit even when you are below the per-minute limit. For example, if you send 10 requests simultaneously and they overlap, up to seven could receive an HTTP 429 Too Many Requests response because of the concurrency limit.

The API can also return HTTP 429 during periods of high platform load, even when your key is within both limits. This protects platform stability and is separate from your key’s usage limits.

Stay within both limits

• Allow no more than three requests in progress across all workers using the same API key. Use a shared worker pool or semaphore, and queue additional requests.
• Separately control the request rate to stay within 200 requests per minute. A concurrency limit alone does not enforce this limit.
• For large jobs, spread requests steadily rather than sending bursts. Include retries in your request-rate budget.

Handle HTTP 429 responses

If a response includes a Retry-After header, wait at least that long before retrying. Otherwise, use exponential backoff—for example, wait 1 second, then 2 seconds, then 4 seconds—with a small random delay added to each wait.

Send retries through the same rate and concurrency controls as other requests. Limit retries by attempt count or elapsed time. If HTTP 429 responses persist, pause the job and contact your Customer Success Manager with the request timestamps and redacted error details. Never include your API key.

Handle other failures

Use the response status to decide whether an unchanged request is worth retrying:

For read requests, a practical starting policy is four attempts total (the initial request plus up to three retries), with waits of 1, 2, and 4 seconds plus jitter, and a finite timeout on every attempt. These are client recommendations, not API service guarantees. Honor Retry-After when supplied; if the required wait exceeds your job's time budget, pause or stop instead of retrying early.

Keep the endpoint, query/body, and pagination cursor unchanged while retrying a failed page. Advance the cursor only after a successful, validated response. If retries are exhausted, report the job as incomplete and retain the last successfully processed cursor for diagnosis. Never report a partial traversal as complete.

For a working implementation, see Paginate search results.

These limits apply to the Crunchbase Enterprise REST API. Do not assume they also apply to MCP connections.

For step-by-step diagnosis of failed requests, empty results, or missing fields, see API troubleshooting.

Collections

Use the endpoint type that fits your workflow:

• Retrieve a specific entity: use the Entity Lookup API.
• Search for entities or page through matching records: use the Search API.
• Find suggested entities by name: use the Autocomplete API.

Terms and attribution for using the API

We encourage you to leverage the API for your internal business and research needs. Unless otherwise noted in your license (see License Agreement and Data Access Terms), you may not license, sublicense, sell, offer to sell, distribute or otherwise provide any of the Crunchbase data to any third parties.

Attribution requirements

When sharing information about the data, follow these attribution requirements:

• Attribution must be accompanied by a hyperlink to Crunchbase.
• If the content being attributed is primarily about one entity, the link must point to that entity on Crunchbase.
• The link must be plainly visible to the end user.
• The link must be in close proximity to the attributed data.
• The link must be visible to Internet spiders (e.g. Googlebot).
• The link cannot include the “nofollow” tag.