1
Choose a product from the catalog
Call
GET /catalog to list the verification products available to your workspace, their required fields, allowed selections and prices in UGX. Store product identifiers, required field names and exact select values in your integration. Use the response to build your submission form.2
Obtain lawful authorisation and request consent wording
You must confirm that the data subject has consented or that another lawful basis applies. Use the fields you intend to submit to request the exact confirmation text:The response returns
data.consentText for your account and subject. Present this text for genuine confirmation. Do not silently accept it.3
Submit the verification with an Idempotency-Key
Include
Idempotency-Key in the request header. The key must be 8-100 characters of letters, digits, ., _, :, or -.4
Handle the response
200 means a completed result is returned immediately. 202 means the check is pending. Do not create another check for the same subject. Store the returned sessionId for polling or webhook correlation.5
Retrieve or receive the final result
Poll
GET /verifications/{sessionId} no more frequently than every 15 seconds, or handle the verification.completed webhook. Only records in your workspace are returned.Verification states
Both matching and no-match results are charged at the catalog price. Failed checks are not charged. Pending checks have no charge until a final result.
Wallet and billing
Your workspace wallet balance is read-only through the API. Manage funding in the MasterID app. A balance check is not a reservation: other workspace activity can change the balance before a verification is submitted. Ensure sufficient funds before you submit each check.End-to-end examples
The examples below read credentials from environment variables, fetch the catalog, request consent, submit a verification, and poll for the result.Sequence diagram
Common pitfalls
Skipped or silently accepted consent
Skipped or silently accepted consent
The
consentText returned by POST /verifications/consent is specific to your account, product and subject fields. You must present it for genuine confirmation from the data subject. Submitting consentConfirmed: true without real confirmation violates the integration agreement.Changed identity after consent
Changed identity after consent
If any identity detail or the consent text changes, request fresh consent wording before submission. A mismatch between the submitted
fields, product and the consent text may result in a rejection or failed check.Polling too frequently
Polling too frequently
If the response is
202 pending, wait at least 15 seconds between polls. Excessive polling wastes resources and can trigger rate limiting.Insufficient wallet balance
Insufficient wallet balance
A balance check is not a reservation. Verify your balance before each submission and keep a buffer, because other workspace activity or charges can change the balance in between calls.
Duplicate checks for the same subject
Duplicate checks for the same subject
Reusing the same
Idempotency-Key with identical parameters returns the saved outcome and does not start a second operation. Changing the body under a used key can return an idempotency conflict. If an original request is interrupted, use the saved session reference rather than creating a new key.Mixing up session and request IDs
Mixing up session and request IDs
The API request
id is returned in every response envelope. The sessionId (6-12 digits) identifies the verification and is what you poll. Store the sessionId from the submission response.
