Quickstart

By the end of this page you will have a working decision flow: a data model, a scenario, a rule, and a decision that comes back with its reasoning.

Create an API key

In the management UI, go to Settings → API Keys and generate one. The key is shown once; if you lose it you generate a new one.Every request carries it in the X-API-KEY header.

Define your data model

Under Your Data, create a table and add its fields. The field names are the names you choose — Krino does not impose a schema.Two fields are required on every table: object_id, which identifies the record, and updated_at, which versions it.More in Data model.

Send an event

curl -X POST https://api.krino.uk/api/ingestion/card_payment \
  -H "X-API-KEY: $KRINO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "object_id": "tx-88214",
    "updated_at": "2026-08-06 10:00:00",
    "customer_no": "M10471",
    "basket_total": 12500.00,
    "client_ip": "203.0.113.45"
  }'

A 202 means the record was accepted and queued for storage. Validation happens before the response: an unknown table, a missing object_id or a field of the wrong type is refused with 400 and an explanation.

Build a scenario and a rule

Scenarios → New scenario, pick the table, then add the version’s rules. Each rule is a condition tree and a score. You set the thresholds here too: review, block-and-review and decline.More in Scenarios and rules.

Ask for a decision

curl -X POST https://api.krino.uk/api/decisions \
  -H "X-API-KEY: $KRINO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "scenario_id": "019fd100-0000-7000-9000-000000000001",
    "object_type": "card_payment",
    "with_rule_execution_details": true,
    "trigger_object": {
      "object_id": "tx-88214",
      "updated_at": "2026-08-06 10:00:00",
      "customer_no": "M10471",
      "basket_total": 12500.00,
      "client_ip": "203.0.113.45"
    }
  }'

The response

{
  "decision": {
    "outcome": "BlockAndReview",
    "score": 92,
    "scenario_name": "E-commerce payment risk",
    "scenario_version": 3
  },
  "rule_executions": [
    { "rule_name": "Disposable email provider", "outcome": "hit", "score": 40 },
    { "rule_name": "Datacenter / VPN egress", "outcome": "hit", "score": 30 },
    { "rule_name": "Unusual basket total", "outcome": "hit", "score": 25 },
    { "rule_name": "Sanctions list match", "outcome": "no_hit", "score": 0 }
  ],
  "execution_time_ms": 34
}

Leaving with_rule_execution_details at false returns only the outcome and score. Turn it on anyway — if a dispute arrives later, the reasoning cannot be reconstructed after the fact.

Before a rule goes live, test it — both against sample data and as a shadow run over real traffic.

Getting started

Platform

Decisions

Data and events

Signals and screening

Self-hosting

The response

Next

​The response

​Next

The response

Next