Cross-app verification

The verify gateway

When a venue on your app needs to prove who it is, deep-link the user to the Kweli gateway:

https://kweli.mukoko.com/[locale]/verify?entity=<entityId>
https://kweli.mukoko.com/[locale]/verify?place=<placeId>&source=<yourapp>

Query param	Required	Meaning
`entity`	no	The `entity.entities` UUID to verify
`place`	no	The `places.places` UUID — the gateway resolves the venue’s entity via `ownerEntityId`
`source`	no	Your app’s identifier (e.g. `nhimbe`, `bushtrade`) for attribution

The gateway resolves the venue, shows the current verification tier, the claim action for representatives, and the community vouch panel for everyone else.

With no query params, /verify is a valid entry point rather than a 404: it renders a venue finder (search the graph by name), the signed-in user’s owned venues and pending claims, and the tier ladder. Linking bare /verify is fine when your app doesn’t know the venue’s UUID.

Rendering the badge

Read bundu.verificationTier from the venue’s graph document and render the mineral-tiered badge (the nyuchi-verified-badge contract): 1 Community/Terracotta, 2 Identity/Cobalt, 3 Government/Gold, 4 Licensed/Tanzanite. The badge is read-only in your app — see the tier ladder.

Example: integrating from Nhimbe

An event on Nhimbe is hosted at a venue. Nhimbe shows the venue’s badge and offers a verify CTA when the venue is unverified:

// Badge: read-only, straight from the graph document
<VerifiedBadge tier={venue.bundu?.verificationTier} />

// CTA: deep-link to the Kweli gateway — no local flow
const verifyUrl =
  `https://kweli.mukoko.com/${locale}/verify` +
  `?place=${venue.id}&source=nhimbe`;

That is the entire integration: one read (bundu.verificationTier) and one link. When the operator completes verification on Kweli, the tier updates in the graph and Nhimbe’s badge reflects it on the next read.