INTEGRATION

APIs your finance system can actually use

A versioned, documented, read-only API that hands your indigent register to your financial system — keyed on the account number it already uses, and stamped with your own mSCOA segments.

The two calls that matter

Who to subsidise

GET /api/Finance/v1/register

Every household that should currently be receiving a subsidy. A full snapshot, safe to poll on whatever cycle your billing run uses — importing it twice changes nothing.

Who to stop subsidising

GET /api/Finance/v1/changes

Every account whose subsidy state has changed since a date you choose. SUBSIDISE for newly approved households, CEASE for those rejected, deceased or no longer qualifying.

The second one is the call most municipalities have never had. A household that dies or stops qualifying keeps drawing a subsidy for as long as nobody tells finance — which is why those beneficiaries turn up in audit findings years later.

ACCESS

Gated by design

Access is by integration key, issued by UbuntuSoft on request. You ask, we issue, and you can see every key held against your register at any time. Keys are not staff logins — a vendor polling nightly should never hold an employee's credentials.
Scoped to one municipality. A key can only ever see the register of the municipality that issued it.
Read-only, permanently. There is no write permission anywhere in this API. Nothing holding a key can alter your register.
Revocable, and immediately. Ask us to withdraw a key and the next request fails. No waiting for a token to expire.
Optional expiry, so a credential issued for a project does not outlive it.
Stored as a hash. The key is shown once when created and never again — not by us, not to us. If it is lost, revoke it and issue another.
One register of every key. Because we issue them, there is a single record of every credential in existence — who holds it, when it was last used and when it lapses. A municipality cannot quietly mint its own.
Usage is visible. Every key records when it was last used, so one nobody is using can be spotted and withdrawn.

For your vendor's developer

The full specification is published as OpenAPI 3.0 — hand it to whoever maintains your financial system and they can generate a client from it.

Standard conventions

Authenticate with Authorization: Bearer or X-Api-Key — whichever your vendor's stack expects. JSON, paginated, versioned in the path so a future change cannot break an integration you have already scheduled.

mSCOA segments, yours

Project, funding, function, item, region and costing segments are configured by your own finance office and stamped onto every record. We never derive or guess them — a wrong segment misstates your books.

Start with one call

GET /api/Finance/v1/whoami confirms a key works and reports what it can reach, so your vendor can prove the connection before writing anything else.

WHAT IT DOES NOT DO

It tells you who qualifies, not what they receive

Tariff policy decides the value of a subsidy, and that lives in your financial system where it belongs. We say which households qualify, from when, and on which account — your system applies the benefit. Anything else would be us inventing figures for your books.

Prefer a file to an API?

The same data downloads as CSV on your own cycle — no integration project required.

Talk to us