Participant Jurisdictions

From an integration standpoint, these endpoints let you build eligibility logic into your own onboarding flow instead of discovering problems only after you submit a participant. Rather than hard-coding a list of supported countries or guessing whether a user can be onboarded, you query zerohash directly as the source of truth.

Typical engineering uses:

  • Drive UI and form validation — populate country/region drop downs from List countries and List jurisdictions so users can only select supported locations, instead of maintaining a static list that drifts out of sync with zerohash.
  • Pre-flight eligibility gating — call Evaluate onboarding before submitting a participant to confirm they're eligible for the given country/jurisdiction (and product). This lets you fail fast, show the user a clear message, and avoid wasted or rejected onboarding submissions.
  • Conditional flows — branch your onboarding logic (e.g. which documents to collect, which products to offer) based on the jurisdiction and eligibility result rather than assuming a one-size-fits-all path.
  • Stay current automatically — because supported countries and jurisdictions change over time, pulling them at runtime (or caching and refreshing) keeps your integration aligned with zerohash without a code change on every regulatory update.

Endpoints

  • List countries — Returns the list of countries zerohash supports, so you can validate or present valid country options before onboarding a participant.
  • List sub-divisions — Returns the supported jurisdictions (country and, where applicable, state/region-level detail) that govern where a participant can be onboarded and which products are available.
  • Evaluate onboarding — Checks whether a prospective participant is eligible to be onboarded for a given country/jurisdiction, so you can determine eligibility up front rather than after a failed submission.