> For the complete documentation index, see [llms.txt](https://docs.coresignal.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coresignal.com/guides/collect-enrich-or-bulk-collect.md).

# Choosing How to Collect: Collect, Enrich or Bulk Collect

Choose the right workflow for collecting and enriching data at any scale.

Once matching records have been identified, whether through [Search Filters](/api-introduction/requests/search-filters.md), an [Elasticsearch DSL](/api-introduction/requests/elasticsearch-dsl.md) query, or an ID, shorthand name, or URL obtained elsewhere, the next step is to retrieve the underlying data. Collect, Enrich, and Bulk Collect handle this.

All three retrieval methods perform the same core task: converting an identifier (an ID, a URL, or a query) into a complete data record. They differ in the input they require and in the number of records returned per request. Selecting the appropriate method reduces unnecessary [credit consumption](/pricing/pricing.md) and simplifies integration. This guide explains each method, when to use it, and how to construct an initial query.

## Overview

The key distinction to retain is this: Collect and Enrich each return a single record per request, whereas Bulk Collect returns multiple records. The remaining differences concern how the record or records are specified.

| Method       | Input                                                 | Output                               | Typical use case                                 |
| ------------ | ----------------------------------------------------- | ------------------------------------ | ------------------------------------------------ |
| Collect      | An ID or a shorthand name                             | One record                           | The exact record to retrieve is already known    |
| Enrich       | A website or social media URL                         | One record                           | A URL is available (e.g., from a CRM) but no IDs |
| Bulk Collect | A list of IDs, filters, or an Elasticsearch DSL query | Multiple records in a single request | Hundreds or thousands of records are required    |

## Collect requests

A Collect request is the most direct API call: a single GET request that returns a specific record. Collect requests typically follow a Search Filter or an Elasticsearch DSL query because those queries return matching IDs, not full records. Collect step converts an ID into a complete profile, including all fields documented in the data dictionary.

When to use it:

* A company, employee, or job ID is already available from a previous search or an existing database, or you have a shorthand name.
* Only one record is necessary per request, such as when a user views individual profiles within an application.
* Accurate control over the returned record is essential.

{% code title="Collect a full record by ID sample" expandable="true" %}

```json
curl -X 'GET' \
  'https://api.coresignal.com/cdapi/v2/company_multi_source/collect/1234567' \
  -H 'accept: application/json' \
  -H 'apikey: {API Key}'
```

{% endcode %}

**Collect using a shorthand name**

Collect accepts more than just numeric IDs. Many endpoints also support a shorthand name, which is a readable slug that identifies a profile on its source platform, like "apple" for a company page. This is particularly helpful when you know the company's public page but not its numeric ID.

{% code title="Collect a full record by shorthand name sample" expandable="true" %}

```json
curl -X 'GET' \
  'https://api.coresignal.com/cdapi/v2/company_multi_source/collect/apple' \
  -H 'accept: application/json' \
  -H 'apikey: {API Key}'
```

{% endcode %}

To differentiate between them: an ID is the numeric value that Coresignal assigns to a record (e.g., `1234567`), whereas a shorthand name is a human-readable slug derived from the profile's URL (e.g., `apple` from `.../company/apple`). Both options refer to the same record, and you can use either depending on which is available.

**Collect selected fields**

The `fields` parameter allows you to specify only the necessary fields instead of the entire record, reducing response size and easing subsequent processing.

{% tabs %}
{% tab title="Collect specified fields by ID" %}
{% code title="" overflow="wrap" expandable="true" %}

```json
curl -X 'GET' \
  'https://api.coresignal.com/cdapi/v2/company_multi_source/collect/1234567?fields=company_name&fields=industry&fields=employees_count' \
  -H 'accept: application/json' \
  -H 'apikey: {API Key}'
```

{% endcode %}
{% endtab %}

{% tab title="Collect specified fields by shorthand name" %}
{% code title="" overflow="wrap" expandable="true" %}

```json
curl -X 'GET' \
  'https://api.coresignal.com/cdapi/v2/company_multi_source/collect/apple?fields=company_name&fields=industry' \
  -H 'accept: application/json' \
  -H 'apikey: {API Key}'
```

{% endcode %}
{% endtab %}
{% endtabs %}

You can include unlimited `fields=` parameters where each one adds an additional field to the response.

## Enrich requests

Enrich functions similarly to Collect but requires a website or social media profile URL instead of an ID. This approach is ideal when beginning with a web address rather than an ID, which is common with CRM records, spreadsheets, and lead lists.

When to use it:

* Enriching existing CRM or lead list records when only a company website or a profile URL is available.
* The Coresignal ID is unavailable, and a separate search is not preferred.
* Building a workflow in which users submit a link and expect to receive data in return.

Enrich endpoints handle different URL formats, such as URLs with or without `https://`, `www`, trailing slashes, or subdomains, and correctly resolve them to the appropriate record.

{% code title="Enrich a company by website" expandable="true" %}

```json
curl -X 'GET' \
  'https://api.coresignal.com/cdapi/v2/company_multi_source/enrich?website=apple.com' \
  -H 'accept: application/json' \
  -H 'apikey: {API Key}'
```

{% endcode %}

{% code title="Enrich specified fields by website" overflow="wrap" expandable="true" %}

```json
curl -X 'GET' \
  'https://api.coresignal.com/cdapi/v2/company_multi_source/enrich?website=apple.com&fields=id&fields=company_name' \
  -H 'accept: application/json' \
  -H 'apikey: {API Key}'
```

{% endcode %}

{% hint style="success" %}

#### In summary

Collect needs an ID or shorthand name, and Enrich requires a URL. Aside from that, both methods work the same way.
{% endhint %}

## Bulk Collect requests

Collect and Enrich work well for retrieving individual records but are not practical for processing hundreds or thousands of profiles, since that would require managing many individual requests. Bulk Collect overcomes this limitation by enabling a single request to retrieve multiple records using various inputs:

* A list of IDs
* Search Filters 
* An Elasticsearch DSL query

Because Bulk Collect requests may return many records and consume more credits, it's advisable to first test your search filter or Elasticsearch DSL query using the standard Search or Collect endpoints. This lets you see the number of matching records before executing the bulk request.

{% hint style="warning" %}
The request below initiates only a bulk collection query and does not return record data directly. To get the data, you need to make follow-up requests.
{% endhint %}

{% code title="Bulk collect using Elasticsearch DSL" overflow="wrap" expandable="true" %}

```json
curl -X 'POST' \
  'https://api.coresignal.com/cdapi/v2/data_requests/company_clean/es_dsl' \
  -H 'accept: application/json' \
  -H 'apikey: {API Key}' \
  -H 'Content-Type: application/json' \
  -d '{
    "webhook_url": "{optional_webhook_url}",
    "limit": 50,
    "es_dsl_query": {
      "query": {
        "bool": {
            "must": [
                {
                    "query_string": {
                        "query": "AI agents",
                        "default_field": "description",
                        "default_operator": "and"
                    }
                }
            ]
        }
    }
}'
```

{% endcode %}

Bulk Collect is a broader topic on its own. Unlike Collect and Enrich, it involves multiple requests to obtain data (one to submit the query and others to retrieve the files), along with dedicated POST and GET endpoints, and file management. These aspects are explained in the dedicated [Bulk Collect guide](/guides/bulk-collect-guide.md).

## Typical workflow

Most users combine these methods rather than picking just one:

{% stepper %}
{% step %}
Search (Search Filters or Elasticsearch DSL) to find matching IDs.
{% endstep %}

{% step %}
Collect each ID for which you want the full record, or Enrich if you're starting from a URL instead of an ID.
{% endstep %}

{% step %}
Switch to Bulk Collect when your workflow needs hundreds or thousands of records at once, instead of looping through single requests.
{% endstep %}
{% endstepper %}

## Related reading

| Resource                                                             | Text Description                                                   |
| -------------------------------------------------------------------- | ------------------------------------------------------------------ |
| [Search Filters](/api-introduction/requests/search-filters.md)       | Identify matching IDs using simple filters                         |
| [Elasticsearch DSL](/api-introduction/requests/elasticsearch-dsl.md) | Identify matching IDs using advanced queries                       |
| [Credits](/api-introduction/credits.md)                              | Details on credit deduction for Collect, Enrich, and Bulk Collect  |
| [Bulk Collect](/api-introduction/requests/bulk-collect.md)           | A full walkthrough of bulk endpoints, webhooks, and request limits |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.coresignal.com/guides/collect-enrich-or-bulk-collect.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.