Risk API reference

Base URL and authentication

https://trustauthy-api.reiun-ni.workers.dev

Send Authorization: Bearer <TENNTO_API_KEY>. Keys are scoped to a user; a run is accessible only to keys belonging to its owner. API keys do not authorize dashboard or API-key-management endpoints.

• OpenAPI 3.1 JSON — Generated from the shared request and result validation schemas. This is the complete field-level contract.

POST /v1/risk

Submit application/json, no more than 16,384 bytes. Unknown request fields are rejected. Fast mode returns HTTP 200 with runId, status "completed" and result. Default mode returns HTTP 202 with runId and status "queued".

Solana addresses also undergo decoded-byte-length validation on the server. JSON Schema can describe the alphabet and string length, but not this entire custom validation.

GET /v1/risk/{runId}

The run ID must contain 1–128 ASCII letters, digits, underscores or hyphens. Returns HTTP 200 with runId, status and result. Result is null until output is available and can be partial before the workflow ends. Responses use Cache-Control: no-store.

Current risk-service statuses: queued, running, completed, failed, canceled. The shared response schema also includes credits_exhausted; clients should handle it as terminal. Report statuses: pending, skipped, completed, failed. These lifecycle statuses are distinct from assessment.status and sanctions status.

Result includes mode, assessment, evidence, report, reportStatus and timings. Assessment includes a nullable score, status, source, sanctions, limitations and policyVersion. Consult OpenAPI for all fields, optional evidence and nullability.

Current quotas

• 300 authenticated risk API requests per minute per user, across keys; GET polls and POST starts both count.
• 20 assessment starts per 24 hours per user, across keys.
• Quota windows start on first use, not at a fixed calendar boundary. Rejected requests may consume quota after authentication. Quotas are not a paid-plan or latency guarantee.

A 429 response does not guarantee a Retry-After header. Back off and use a bounded retry policy rather than a tight polling loop. Do not automatically retry POST submissions whose outcome is uncertain.

Error responses

{
  "error": {
    "code": "validation_error",
    "message": "Request validation failed",
    "details": []
  }
}

The error object contains code and message; details is optional and is used for validation issues. Do not rely on human-readable message text as a stable discriminator.