KYTRIX developer documentation

#Start here

If you are integrating for the first time, read the integration guide end to end once before writing code. It is ordered the way the work is: sign a request, get money and time right, retry safely, handle errors, receive webhooks, prove it with the conformance CLI.

#What KYTRIX is

A financial-crime control plane. You send facts about your business — customers, accounts, instruments, movements, relationships and what your own controls did. KYTRIX builds a canonical model and a behavioural and network picture on top of it, and hands back alerts, episodes and a banded risk posture.

• Explicit non-results. A detector that cannot answer says insufficient_data, stale or not_applicable. It never invents a neutral value, and posture can come back unknown or incomplete — real answers, not errors.
• Nothing is acknowledged and then lost. The 202 on an ingest call is returned only after one database transaction has committed both the raw event and its processing obligation.
• Corrections are new records. Movements, control events, evidence and audit records are never edited in place; a correction is a new event that references the original.

#The shape of it

#The shortest real request

Every request is HMAC-signed; there is no bearer token. The dry-run is the right first call because it proves your signing without writing anything:

import { KytrixClient } from '@kytrix/sdk';

const kytrix = new KytrixClient({
  baseUrl: process.env.KYTRIX_BASE_URL!,   // https://api.<your-domain>
  keyId:   process.env.KYTRIX_KEY_ID!,     // kx_test_… in the sandbox
  secret:  process.env.KYTRIX_API_SECRET!, // shown once at key creation
});

const report = await kytrix.validate({
  object: 'movement',
  event: {
    external_id: 'ledger-8842',
    schema_version: '2026-09-01',
    occurred_at: '2026-09-02T09:15:00-04:00',
    data: {
      type: 'p2p',
      status: 'completed',
      amount: { value: '180000', asset: 'DOP', scale: 2 },   // 1,800.00 DOP — a STRING
      debit:  { account_id: 'wallet-1' },
      credit: { account_id: 'wallet-2' },
    },
  },
});

console.log(report.valid, report.results);

Not on Node? The integration guide has the same request as plain HTTP, with a dependency-free signing implementation that is executed against the published test vectors every time these docs are built.

#The three things people get wrong

#How these docs are produced

The API reference, the error catalog, the webhook catalog and the worksheet’s target paths are generated from the same zod schemas the server validates against, at build time. A hand-maintained reference drifts from the contract; this one cannot.

• 31 documented operations, 19 generated schemas, 38 error codes, 19 webhook event types.
• Endpoint paths are checked against the source file that registers them: if a route moves and this table does not, the docs build fails.
• Both published code snippets — request signing and webhook verification — are executed against the shipped test vectors during the build.
• The mapping-worksheet templates are parsed by the real import mapping schema during the build.
• An OpenAPI 3.1 document is emitted from the same source.