SLA and timeouts
The SLA window and what happens on timeout.
SLA window
The SLA window is the maximum time Tekmerion waits for a valid KYT response after dispatching the request. The default is 60 seconds. Merchants MAY configure a different value per KYT endpoint at setup.
The timer starts when Tekmerion dispatches the request to the registered endpoint URL. It is not reset on connection delays or partial responses. A valid response that arrives after the SLA window has expired MUST be discarded; the timeout resolution already applied is final.
What counts as a timeout
An invocation times out if:
- No HTTP response is received within the SLA window.
- An HTTP response arrives within the SLA window but fails field-level validation (treated as no valid response for SLA purposes).
Network-level errors (connection refused, DNS failure, TLS error) are failures, not timeouts, but also count toward the consecutive-failure counter. See Endpoint health and suspension.
default_on_timeout policy
Each KYT endpoint configuration includes a default_on_timeout policy that governs what Tekmerion does when no valid response is received within the SLA window.
| Policy | Behavior | Opt-in required |
|---|---|---|
hold | The attempt enters hold state. Tekmerion schedules a re-invocation per the platform retry schedule. | No — this is the default-safe policy. |
auto_approve_to_main | Tekmerion applies approve using the merchant's pre-registered primary wallet address as sweep_to. | Yes — requires explicit opt-in with signed acknowledgment. |
auto_refund | Tekmerion applies reject using the merchant's pre-configured default refund address as refund_to. Not available in v1.0. | Yes — requires explicit opt-in and a default refund address configured at onboarding. |
auto_approve_to_main and auto_refund MUST NOT be activated without explicit merchant acknowledgment of the operational implications. hold is the only policy applied by default. auto_refund is not supported in v1.0.
Destination address requirements for auto policies
When auto_approve_to_main or auto_refund applies, the destination address Tekmerion uses MUST be a member of the merchant's destination whitelist. The same whitelist constraints that apply to explicit decisions apply to timeout-resolved decisions.
Effect on failure counter
A timeout counts toward the endpoint's consecutive-failure counter regardless of which default_on_timeout policy is applied. A successful invocation resets the counter. See Endpoint health and suspension.
Hold on timeout
When default_on_timeout = hold, the timeout resolves identically to the merchant returning decision = hold. Tekmerion schedules a re-invocation per the platform's retry schedule. The retry_after field does not apply — Tekmerion uses its own schedule when hold originates from a timeout resolution rather than from the merchant's explicit response. See Hold and retries.