The current integration surface is intentionally small. Use the dashboard to create an API key, check your credit balance, then call the predict endpoint from your application.
Keep the dashboard for account setup. Keep your app focused on the runtime calls.
Log into the dashboard once, create a key, and keep it on the server side.
Use GET /v1/balance to confirm available credits before sending traffic.
Send a 10-digit Nigerian account number to POST /v1/predict.
These are the core routes external developers need right now.
Returns the logged-in account's remaining credits. This route uses the dashboard session cookie, so it is mainly useful for your internal dashboard or operator tooling.
curl "http://127.0.0.1:3000/v1/balance" \ --cookie cookies.txt
Predicts the Nigerian bank or candidate banks for a 10-digit account number. Send
your API key in X-API-Key. A credit is only consumed when the result
resolves to predicted.
curl -X POST "http://127.0.0.1:3000/v1/predict" \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"account_number": "0123456789"
}'
The predict endpoint always resolves into one of three clear outcomes.
A single verified or high-confidence bank match was found.
status: predictedThe service narrowed the result to candidate banks but could not fully resolve one.
status: partialThe account number could not be resolved into a useful prediction.
status: unresolved{
"status": "predicted" | "partial" | "unresolved",
"account_number": "0123456789",
"banks": [
{
"bank_code": "044",
"bank_name": "Access Bank",
"confidence": "high" | "low"
}
]
}