Developers

One key. One base URL. Everything.

The ecosystem API is the whole platform. The partner portal, the data-subject portal, the rewards app and the desktop builds are all clients of it — there is no privileged back channel.

Authentication

Every metered endpoint takes a scoped key issued from the partner portal. Keys are stored as hashes — the full value is shown once, at issue, and never again.

# Bearer is preferred; x-api-key is accepted for legacy clients.
curl https://api.wynk.credit/api/v1/scores \
  -H "Authorization: Bearer wynk_live_…" \
  -H "content-type: application/json" \
  -d '{"subject_id":"sub_…"}'

Test keys carry the wynk_test_ prefix and run the same code paths against sandbox adapters. Live keys carry wynk_live_. Revoking a key in the portal takes effect on the next request.

Open endpoints

These four need no key at all — they exist so that your monitoring, your edge devices and your applicants can work without one.

GET/api/v1/status
GET/api/v1/health
GET/api/v1/issuer
POST/api/v1/credentials/verify

The liveness capture endpoints are also open but token-gated: an applicant completing a WhatsApp liveness link has no key of their own.

Live console

Documentation that answers for itself.

These buttons issue real requests to this server from your browser. If the response below disagrees with the docs above, the docs are wrong.

Try an open endpoint

The last one shows the unauthorised shape: a metered endpoint with no bearer key returns 401 unauthorized with the hint, not a redirect.

Response

live
Ready.
Reference

The surface, in full.

Credit intelligence

POST/api/v1/scores
GET/api/v1/scores/:id
GET/api/v1/subjects/:id/features
POST/api/v1/decisioning
POST/api/v1/propensity

Scoring is consent-gated on credit_scoring and returns the champion score, the challenger score, the 12-month PD, an indicative limit, a fraud probability and the ranked reason codes.

Identity & verification

POST/api/v1/subjects
GET/api/v1/subjects/:id
POST/api/v1/verify
POST/api/v1/credentials
POST/api/v1/credentials/verify

Subject creation is idempotent on the resolved identity: posting the same identifiers twice resolves to the existing subject rather than forking the graph.

FICA & compliance

POST/api/v1/fica
POST/api/v1/africa-direct/fica/batch
POST/api/v1/africa-direct/liveness
GET/api/v1/africa-direct/reviews
GET/api/v1/liveness/:token

The batch and review endpoints are the white-label track: a partner runs CDD for its own customer base inside its own namespace, with its own compliance-officer queue.

Health intelligence

POST/api/v1/health/assess

Gated on the health_intelligence consent purpose. Returns engagement dimensions with their evidence, weighted risk factors, the morbidity index, the hazard band and the actuarial view. Requesting it without the grant returns a consent error, not a partial result.

Merchant track

POST/api/v1/a2pay/ingest
POST/api/v1/a2pay/score
POST/api/v1/a2pay/score/bulk
GET/api/v1/a2pay/merchants
GET/api/v1/a2pay/merchants/:id

Point-of-sale ingestion carries no consumer identity: the merchant is the subject and the cardholder never enters the spine.

Data, consent & DSAR

POST/api/v1/ingest
POST/api/v1/consents
GET/api/v1/subjects/:id/consents
GET/api/v1/subjects/:id/dsar

A subject access request is a single call. It replays every consent, every processing event, every score and every verification against that subject, with the ledger integrity result attached.

Lending book

POST/api/v1/loans/apply
POST/api/v1/loans/:id/disburse
POST/api/v1/loans/:id/repay
GET/api/v1/loans
GET/api/v1/loans/:id

Loan events are hash-chained and free of charge — you are billed for the intelligence, not for writing down what happened.

Webhooks

POST/api/v1/webhooks
GET/api/v1/webhooks
GET/api/v1/webhooks/deliveries
POST/api/v1/webhooks/deliveries/:id/redeliver

Deliveries are signed, retried with exponential backoff by a background worker, and individually redeliverable. A failed delivery is visible, not lost.

Public site API

The endpoints this website runs on.

This site holds no typed-in numbers. It reads three unauthenticated endpoints, which are documented here because you can call them too.

EndpointReturnsRate limit
GET /site/api/overviewAggregate platform state — totals, distributions, chain integrity, registered models and the live price list. Counts per bucket only; no row about any person.60 / minute / IP
POST /site/api/score-demoRuns the registered champion and challenger scorecards over a behavioural vector you supply. Pure — no subject is created, nothing is persisted.30 / 5 minutes / IP
POST /site/api/contactEnquiry capture. The capture is written to the audit chain; the contact detail is not.5 / hour / IP

Errors

Failures return a JSON body with a stable error code and a human message. 401 means no or invalid key, 403 means a consent or permission gate refused, 429 carries retry_after in seconds.

Metering

Every metered call writes a usage line with the product, the outcome and the latency. Failed calls are metered too — you can see them, and so can we. Usage and revenue are visible per product and per day in the portal.

Operations

/api/v1/health reports database driver and latency, hash-chain integrity and length per ledger, adapter modes and the active model set. /metrics exposes Prometheus counters and histograms.

Adapter modes are reported honestly. A sandbox adapter never claims to be live: if /api/v1/health says sandbox, the DHA, bureau, screening and CIPC calls behind it are simulated, and no integration test can accidentally pass against a real registry.