Common headers
Helium ID signs webhook requests with these headers:Webhook-TimestampWebhook-Signature
Individual verification payloads
These payloads apply to sessions created withPOST /v1/verifications.
verification.started
verification.selfie_uploaded
verification.document_front_uploaded
verification.document_back_uploaded
verification.processing_started
verification.biometrics_matched
verification.successful
docInfo
verification.failed
Company verification payloads
These payloads apply to sessions created withPOST /v1/company-verifications.
Shared company fields
Most company-verification webhook events include this common shape:companyProfile
companyProfile gives you the best currently available company-customer data in a stable, integration-friendly shape.
companyProfile.business
companyProfile.contact
companyProfile.authorisedRepresentative
companyProfile.officers
Each officer entry can include:
companyProfile.ownership
companyProfile.authority
companyProfile.additionalInformation
companyProfile.documents
review
The review block helps downstream consumers understand whether the payload is ready for provisioning or still needs more verification/review.
review.provisioning
company_verification.submitted
Uses the shared company fields and includes the normalized companyProfile and review blocks.
company_verification.under_review
Uses the shared company fields.
company_verification.successful
Uses the shared company fields and includes the normalized companyProfile and review blocks.
This event uses the same normalized payload shape as company_verification.submitted. The difference is that the values now describe the successful outcome, including status: "successful" and the corresponding review/provisioning state.
company_verification.failed
Uses the shared company fields. For failed decisions, reason should contain the rejection reason.
company_verification.liveness_completed
Includes the shared company fields plus:
Stability notes
Helium ID may add new optional fields to webhook payloads over time. Your webhook consumer should:- ignore unknown fields safely
- handle new event types without crashing
- store the raw payload for auditing and replay