KYT endpoint setup

The KYT endpoint is where Tekmerion sends each transaction-level compliance decision for your approval. After a deposit is observed and Tekmerion's sanctions screening completes, Tekmerion makes a synchronous call to this endpoint and waits for your approve, reject, or hold decision. The decision is yours — Tekmerion relays it and cannot override it. This page covers registering the endpoint; the runtime request and response contracts live under KYT webhook.

Step 1 — Stand up an HTTPS endpoint

Provide a single HTTPS URL that accepts a POST and returns a decision within your SLA window. It must:

verify the request signature before acting — see Verifying requests;
return a response that conforms to the Response contract;
respond fast enough to stay inside the SLA window (see Step 3).

At most one KYT configuration is active per merchant at a time.

Step 2 — Receive the signing secret

Tekmerion issues a signing secret for the endpoint. Every inbound KYT request is signed with it as X-Tekmerion-KYT-Signature: v1=<hex>, alongside X-Tekmerion-KYT-Timestamp. Your endpoint MUST verify both headers before processing any payload — Tekmerion never sends an unsigned KYT request.

This KYT signing secret is distinct from your notification endpoint secrets. Secrets are not shared across surfaces, and a KYT secret MUST NOT be used to verify notification webhooks.

Tekmerion confirms the endpoint before the configuration becomes active. Only an active configuration receives KYT calls.

Step 3 — Set the SLA window

sla_seconds is the maximum time Tekmerion waits for a valid response after dispatching the request. The default is 60 seconds. The timer starts at dispatch and does not reset on connection delays. A valid response that arrives after the window has closed is discarded — the timeout resolution already applied is final. Full SLA semantics are in SLA and timeouts.

Step 4 — Choose the timeout policy

default_on_timeout governs what Tekmerion does when no valid response arrives within sla_seconds. Choose deliberately — this policy decides what happens to a real payment when your endpoint is unreachable or slow.

Policy	What happens on timeout	Opt-in
`hold`	The payment enters hold; Tekmerion re-invokes later. No funds move and no outcome is finalized.	Default. No opt-in.
`auto_approve_to_main`	Tekmerion applies `approve` using your primary wallet as `sweep_to`. The payment settles.	Explicit opt-in with signed acknowledgment.
`auto_refund`	Tekmerion applies `reject` using your pre-configured default refund address as `refund_to`. The payment is refunded.	Explicit opt-in and a default refund address configured at onboarding.

auto_approve_to_main delegates a compliance decision to a timeout. If your endpoint fails to answer in time, the payment is approved and settled as though you had said approve — a transaction you never reviewed is treated as approved. auto_refund similarly resolves to a refund without your review. hold is the only policy that finalizes nothing on timeout, and it is the default for that reason. Enable an auto policy only with full understanding of this consequence.

For any auto policy, the address Tekmerion uses MUST be a member of your signed destination whitelist — the same constraint that applies to explicit decisions. See Factory authorisation.

After setup

Once active, your endpoint participates in every payment's compliance step. Related runtime behaviour:

Hold and retries — how hold decisions are re-invoked.
Endpoint health and suspension — what sustained failures do to your configuration.