Skip to main content
Helium ID supports both test and live API keys. The integration shape is the same in both environments, but the operational behavior is different. This page gives you a practical matrix you can use when planning your integration and test strategy.

​
At a glance

​
Individual verification behavior

​
Notes for individual verifications

  • Test keys are meant for verifying your integration logic.
  • Live keys are for real end-user verification flows.
  • If you need to test approval and rejection handling end to end, use a test key.

​
Company verification behavior

​
Notes for company verifications

  • Test company verifications can be advanced through review states from the customer dashboard for integration testing.
  • Live company verifications are reviewed and decided by Helium ID.
  • Customer workspace admins should not rely on live dashboard controls for terminal company outcomes.

​
What should be identical in both environments

Your integration should keep these behaviors the same in test and live:
  • request format
  • webhook verification logic
  • event parsing
  • retry behavior
  • storage of vendorData, verification IDs, and event logs
In other words, the difference between test and live should mostly be about who controls the final decision and whether the environment is production-billed, not about your basic integration design.
  1. Build your integration against a test API key
  2. Validate webhook signatures and payload parsing
  3. Test both positive and negative decision handling
  4. Verify dashboard review behavior
  5. Move to a live API key only after you are confident that your webhook and session-handling logic is stable

​
What to communicate internally

If your team includes engineering, operations, and support, make sure everyone knows:
  • which API key environment is being used
  • whether a decision was test-generated or live-generated
  • whether a company-verification outcome came from Helium ID review or customer-admin testing
That context avoids a lot of confusion during QA and support investigations. For practical implementations, see: