Model the request
Send the service code, subject reference, lawful purpose, authority confirmation and idempotency key required for the selected workflow.
Developers
Make the first request feel like the right abstraction.
Build against a clear contract, keep outcomes explicit and give your team the tools to handle uncertainty well.
Integration shape
Small surface. Serious workflow.
Start with a request, receive an explicit outcome, and handle review as a first-class state—not an exception hidden in a log.
- ✓Documented authentication and endpoint patterns.
- ✓Explicit success, no-match and review states.
- ✓Clear path to the Smart Verify documentation team.
curl https://api.smartverify.co.za/v1/verify \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"purpose":"onboarding","subject_ref":"your-ref"}'
// See the docs for the current contract.
// See the docs for the current contract.
A deliberate integration path
Start small. Keep the contract stable.
Build one useful verification journey first, then expand the same operating model across services without teaching every team a different set of rules.
Handle every state
Design for completed, manual review, pending, validation, credit and provider-error responses. A 202 response is not a failed integration—it can be an intentional review boundary.
Keep provider detail behind the layer
Your product receives a consistent SmartVerify contract while source-specific response shapes remain normalised behind the integration boundary.
Test without paid calls
Use validation, rendering and regression tests to exercise your integration logic without consuming provider credits during development.
API principle
request → reservation → provider outcome → review or recorded decision