The boring parts, already done.
A decisioning API is only useful if you can trust the plumbing around it. This page lists what sits under the Credit Engine today, row by row, with an honest status on each.
What is under the endpoint.
Each row is a capability of the engine itself. The status is read from the code, not from a roadmap deck.
| Capability | What it does | Status |
|---|---|---|
| Auth | Tenant-scoped API keys, stored as hashes, with rotation and revocation from the console. | Built |
| Request signing | HMAC signing of request bodies on top of the bearer key. | Roadmap |
| Idempotency | Send an Idempotency-Key and retry safely: the same key returns the same stored decision, never a second one. | Built |
| Rate limiting | Per-tenant monthly decision quotas are enforced today. Per-second request throttling is not built yet. | Roadmap |
| Webhooks | Signed event callbacks for decision, disbursal, repayment and DPD movement. | Roadmap |
| Audit trail | Decisions are append-only at the database level. Every decision and policy change is logged with actor and timestamp. | Built |
| Reproducibility | Any past decision re-runs from its stored inputs against the policy version in force at the time, and reports whether the result is identical. | Built |
| Sandbox | Keys can be labelled test or live and sample reports exist for all four bureau formats. An isolated sandbox data plane is not built yet. | Roadmap |
| Postman | A generated collection covering every endpoint, downloadable from the engine console. | Built |
Built = implemented and tested in our codebase.Partial = core logic built, not production-ready.On onboarding = adapter built, enabled with your vendor credentials.Roadmap = not built yet.Gradexa is in active development; no production lenders yet.
On latency
We do not publish a decision-latency figure yet. The engine path is deterministic and has no LLM in it, but the only load tests so far ran from a developer machine against a remote database, which measures the network more than the engine. When we have numbers from a real deployment, p50, p95 and p99 will appear here with the date and sample size.
See a policy change land, not a month-end surprise.
The goal is a live view per tenant: decisions per hour, approval rate, grade distribution, the knockout reasons that dominate, and latency. If a rule change tanks approvals, you should see it within the hour.
In the console today
- 01Decisions this month against plan quota
- 02Daily decision counts
- 03Active policy version
- 04Pending human reviews
- 05Most recent decisions with outcome, grade and limit
Planned
- 01Decisions per hour
- 02Approval rate over time
- 03Grade distribution
- 04Top knockout reasons
- 05Decision latency
Want to see the plumbing?
Request a demo and we'll show you key rotation, an idempotent retry, and a decision re-run from its stored inputs.