one request.
a plan with its reasons.
Your backend sends data and a versioned model id. kint returns the plan, the limit that binds it, what one more unit of a resource is worth, and the solver's bound and gap. Each run is pinned, so the plan can be re-checked against the record.
POST /v1/runs
- indata and a model idInline or as a reference to a versioned upload.
- outplan, limit, price, bound, gapPlus a record id that pins the run, so it can be re-checked.
what you can rely on.
replayable
The data version, the model version and the settings are pinned per run.
versioned models
Models are immutable once published. You pin a version and upgrade when you choose.
typed responses
Documented fields and typed responses. Status, gap and binding limits sit in fixed places.
async when long
Large runs return a job id you can poll. Short runs answer directly.
request in. plan out.
A shift plan for a container terminal. The model was built and reviewed once. Every night, the backend calls it with fresh data.
- modelPinned to a version. A new version never changes old results.
- dataInline or as a reference to a versioned upload.
- bindingThe limits that decide the outcome, with their shadow prices.
- bound · gapThe solver's bound and the gap to it. At 0.0 %, no better plan exists for the model as stated, within the solver's tolerance.
- recordAn id that pins the data version, the model version and the settings of the run.
{ "model": "terminal-shifts@7", "data": "upload:2027-03-02T18:00", "scenario": { "cranes_out": ["QC-04"] }, "objective": "min_equipment", "time_limit_s": 60}{ "status": "optimal", "gap": 0.0, "plan": { "shifts": [ … ] }, "binding": [ { "limit": "berth_window.vessel_B", "shadow_price": … } ], "bound": …, "record": "rec_…", "pinned": ["data", "model", "solver", "settings"]}Illustrative. Field names and paths are examples, the reference documentation comes with access.
small, on purpose.
A handful of resources cover data, models, runs, scenarios and the record.
| Method | Path | Purpose |
|---|---|---|
| POST | /v1/uploads | Send data. Each upload becomes a version. |
| GET | /v1/models/{id} | Read a model version and its rules. |
| POST | /v1/runs | Solve with a model version and data. |
| POST | /v1/scenarios | Run what-if variants for comparison. |
| GET | /v1/runs/{id} | Plan, binding limits, sensitivity, bound and gap. |
| GET | /v1/records/{id} | Who released what, on which versions. |
from key to production.
Four steps, with engineers from kint on the other end of every one.
access
An API key and the reference documentation.
model
Your domain expert and kint's decision agent build the model. kint's forward deployed engineers (FDEs), who work directly with customer teams, review it with that expert. Then they publish it as a version.
integrate
The backend calls runs and renders plans. kint's FDEs answer developers directly.
operate
Production tenant, hosted in Germany or as a scoped installation in your infrastructure. Releases and records on.
- transportEncrypted in transit (TLS 1.2 or higher) and at rest (AES-256). API keys are issued per tenant.
- dataThe data is not shared with other customers, and kint trains no models for other organisations on it.
- accessRoles and releases. Uploads, model changes, runs and releases are recorded with who acted and when.
- documentationDrafts of the EU AI Act documentation, kept current from the running system, for your compliance team to review.
your backend. our math.
A technical walkthrough with kint's FDEs, on your problem type. Bring the hard questions.
- Format
- REST, JSON, job ids for long runs
- Embedding in a product
- oem partnership
- Contact
- hello@kint.pro