Skip to content

Cross-app verification

When a place or organization 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 paramRequiredMeaning
entitynoThe entity.entities UUID to verify
placenoThe places.places UUID — the gateway resolves the place’s entity via ownerEntityId
sourcenoYour app’s identifier (e.g. nhimbe, bushtrade) for attribution

The gateway resolves the place, 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 place finder (search the graph by name), the signed-in user’s owned places and pending claims, and the tier ladder. Linking bare /verify is fine when your app doesn’t know the place’s UUID.

Read bundu.verificationTier from the place’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.

An event on Nhimbe is hosted at a place. Nhimbe shows the place’s badge and offers a verify CTA when the place 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.