Skip to main content
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:
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:
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:
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

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.