Skip to main content
POST
/
v1
/
credit-boost
Boost credit limit
curl --request POST \
  --url https://api-dev.bsa.ai/v1/credit-boost \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "FullName": "<string>",
  "MobileNumber": "<string>"
}
'
{
  "mobileNumber": 123,
  "finalCreditScore": 123,
  "originalCreditLimit": 123,
  "mankaCreditLimit": 123,
  "finalCreditLimit": 123,
  "boostStatus": "<string>",
  "executionPeriod": "<string>"
}

Documentation Index

Fetch the complete documentation index at: https://docs.api.bsa.ai/llms.txt

Use this file to discover all available pages before exploring further.

Submits a PDF statement (mobile money or bank) to the Manka AI engine. If the statement is valid, recent, and yields a higher limit than the customer’s current one, the customer’s pre-approved limit is increased on the spot. All three outcomes — increased, unchanged, cooldown — return 200 OK with the same response shape; branch on boostStatus and the limit fields.
The upstream always sends an SMS to the customer’s mobile number when this endpoint is called, including on validation failures. Treat every successful call as an outbound communication event.

​
Content type

multipart/form-data

​
Form fields

​
FullName
string
required
Customer’s full name as it appears on the statement. For bank statements, at least two name parts must match the statement (case-insensitive) or the upstream rejects with a name mismatch.
​
MobileNumber
string
required
Exactly 12 digits in international format (e.g. 255762260621). For MNO statements, must match the phone number on the statement exactly.
​
pdf_file
file
required
The statement PDF. See Statement requirements below.

​
Example

curl -sf -X POST "$BASE/v1/credit-boost" \
  -H "Authorization: Bearer $TOKEN" \
  -F "FullName=JOHN DEO MWAMBA" \
  -F "MobileNumber=255762260621" \
  -F "pdf_file=@/path/to/statement.pdf"

​
Response

200 OK — same shape across all three scenarios:

​
Scenario A — Boost applied

{
  "mobileNumber": 255762260621,
  "finalCreditScore": 500,
  "originalCreditLimit": 30000.0,
  "mankaCreditLimit": 55000.0,
  "finalCreditLimit": 55000.0,
  "boostStatus": "YES",
  "executionPeriod": "4.32 seconds"
}
The limit was raised from 30,000 to 55,000 TZS. The customer gets an SMS confirming the new limit.

​
Scenario B — No increase

{
  "mobileNumber": 255762260621,
  "finalCreditScore": 500,
  "originalCreditLimit": 30000.0,
  "mankaCreditLimit": 18000.0,
  "finalCreditLimit": 30000.0,
  "boostStatus": "NO",
  "executionPeriod": "3.91 seconds"
}
Statement passed validation but the Manka-derived limit didn’t exceed the existing one. No database update. Customer is notified by SMS.

​
Scenario C — Cooldown active

{
  "mobileNumber": 255762260621,
  "finalCreditScore": 500,
  "originalCreditLimit": 30000.0,
  "mankaCreditLimit": 30000.0,
  "finalCreditLimit": 30000.0,
  "boostStatus": "NO"
}
The customer was already boosted within the last 45 days. The statement is not reprocessed; the existing limit is echoed back.

​
Fields

​
mobileNumber
integer
​
finalCreditScore
integer
​
originalCreditLimit
number
TZS. Limit before this boost attempt.
​
mankaCreditLimit
number
TZS. Limit derived from the uploaded statement.
​
finalCreditLimit
number
TZS. max(originalCreditLimit, mankaCreditLimit) after a successful evaluation; otherwise echoes originalCreditLimit.
​
boostStatus
string
YES if the limit was raised; NO otherwise (including the cooldown case).
​
executionPeriod
string
Upstream processing time. Diagnostic only.

​
Statement requirements

RequirementDetail
FormatPDF only (.pdf)
Accepted sourcesAirtel, Yas, Vodacom, Halotel, NMB, CRDB
Rejected sourcesHaloPesa, Selcom, any other institution
RecencyLast transaction within the past 14 days
Coverage — AirtelMinimum 15 days of history
Coverage — all othersMinimum 60 days of history
MNO matchPhone number on statement must equal MobileNumber
Bank matchAt least 2 name parts on the statement must match FullName
AuthenticityUnedited original, direct from the provider

​
Errors

The upstream uses several non-standard status codes. We translate them onto our standard error code surface:
CodeCaused by
invalid_argumentFile is not a PDF (upstream 400); statement processing failed (402); name/phone mismatch (405); statement not recent enough (406); statement source unsupported, insufficient coverage, or other validation failure surfaced as upstream 401
failed_preconditionStatement appears tampered or forged (upstream 403); customer not eligible — current limit ≤ 500 TZS (upstream 500)
unauthenticatedToken missing/invalid (upstream 401 with detail "Invalid or missing token")
unavailableUpstream Manka engine unreachable (upstream 502)
internalDatabase write failed after a successful boost compute (upstream 998); other unhandled server error (501)
The upstream returns 401 for both genuine auth failures and several business-validation failures (unsupported source, HaloPesa statement, insufficient coverage). In those latter cases the wrappers API translates to invalid_argument, not unauthenticated. If you need to distinguish, inspect the message field — auth failures contain the literal string "Invalid or missing token".