> ## Documentation Index
> Fetch the complete documentation index at: https://docs.heliumid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# IDs and Terminology

> Understand the important Helium ID identifiers and terms used across individual and company verification flows.

Helium ID uses a few identifiers that sound similar but serve different purposes. This page explains what each one means and where you will see it.

## Individual verification IDs

### `verificationId`

For individual verifications, `verificationId` is the main verification record ID.

You will see it in:

* the response from `POST /v1/verifications`
* the path for `GET /v1/verifications/{id}`
* individual verification webhook payloads
* the hosted link query parameter as `processId`

In other words, for individual verifications:

* `verificationId` and hosted-flow `processId` refer to the same underlying verification record

### `processId`

`processId` is the query parameter in the hosted verification link.

Example:

```text theme={null}
https://verify.heliumid.io/?processId=69d4f7657bcbe3b58b96b2f7
```

For individual verifications, this is the same value as the returned `verificationId`.

## Company verification IDs

Company verifications use two different identifiers on purpose.

### Public company verification ID: `verificationId`

When you create a company verification with `POST /v1/company-verifications`, the response returns:

```json theme={null}
{
  "data": {
    "verificationId": "cv_0b5f6f4e0aab25d8c130ab21"
  }
}
```

That returned `verificationId` is the company's **public ID**. In the data model it is stored as `externalId`.

You should use it for:

* storing a customer-facing company verification reference
* correlating company verification webhooks with your own records
* internal support and operations workflows

### Internal company verification ID: `companyVerificationId`

Company-verification webhooks include `companyVerificationId`.

That is the internal database record ID for the company verification.

You will also see this internal ID in the hosted link as `processId`.

### Hosted company `processId`

Example:

```text theme={null}
https://verify.heliumid.io/company?processId=69d4f7657bcbe3b58b96b2f7&hostedToken=...
```

For company verifications:

* hosted-link `processId` = internal company verification ID
* webhook `companyVerificationId` = internal company verification ID
* create-response `verificationId` = public company verification ID (`externalId`)

That distinction is one of the most important differences between the individual and company flows.

## `externalId`

`externalId` is the public ID stored on a company verification.

It is:

* returned as `verificationId` in the company verification create response
* included in company-verification webhook payloads

It is not currently used as the hosted `processId`.

## `vendorData`

`vendorData` is your own correlation value.

Typical examples:

* your user ID
* your business ID
* your application ID
* your onboarding case ID

Helium ID stores and echoes this value back in webhooks and verification records where available. It is one of the easiest ways to match Helium ID records to your own system.

## `meta`

On create endpoints, `meta` lets you attach additional structured information to the verification.

In the models, this is stored as `userMeta`.

Use it for:

* non-critical contextual data
* workflow hints
* integration-specific metadata

Do not rely on `meta` as the only way to correlate records. Use `vendorData` for your primary correlation key.

## `campaignId` and `campaignVersion`

These apply to company verifications created from a campaign configuration.

* `campaignId` identifies the company-verification campaign
* `campaignVersion` identifies the published version used when the session was created

They are returned in the company create response and echoed in company webhook payloads when present.

## `hostedToken`

Company verification hosted links include a `hostedToken`.

This token authorizes access to the hosted company flow. You should:

* treat the full link as opaque
* store or forward it exactly as returned
* avoid rebuilding it yourself

Do not remove the `hostedToken` from the URL.

## Quick mapping table

| Term                    | Flow       | Meaning                                                  |
| :---------------------- | :--------- | :------------------------------------------------------- |
| `verificationId`        | Individual | Main verification record ID and hosted `processId`       |
| `verificationId`        | Company    | Public company verification ID, also called `externalId` |
| `companyVerificationId` | Company    | Internal company verification record ID                  |
| `processId`             | Individual | Internal verification ID used by the hosted link         |
| `processId`             | Company    | Internal company verification ID used by the hosted link |
| `externalId`            | Company    | Public company verification ID                           |
| `vendorData`            | Both       | Your own correlation identifier                          |
| `meta`                  | Both       | Additional custom metadata                               |
| `campaignId`            | Company    | Campaign identifier                                      |
| `campaignVersion`       | Company    | Campaign version used                                    |
| `hostedToken`           | Company    | Secure hosted-flow token                                 |

## Recommended storage strategy

For individual verifications, store:

* `verificationId`
* `vendorData`
* environment used

For company verifications, store:

* public `verificationId` from the create response
* internal `companyVerificationId` from webhooks when it first arrives
* `vendorData`
* environment used

That gives you stable correlation across API calls, dashboard operations, and webhooks.