Skip to main content
Tusi
API reference

API reference

Response contracts, health checks, error handling, and secure patterns for consuming platform APIs.

8 min readCurrent API version
Verified against the current implementation
01

Response contract

Application APIs use a consistent envelope. Successful responses provide status and data; failed responses provide a message suitable for display or logging.

jsonTusi
{
  "status": "success",
  "data": { "id": "resource_id" }
}

{
  "status": "error",
  "message": "A human-readable error"
}
02

GET /api/health

Use this endpoint to check application and database availability. HTTP 200 indicates healthy dependencies; HTTP 503 indicates a dependency failure.

jsonTusi
{
  "status": "healthy",
  "timestamp": "2026-09-11T08:30:00.000Z",
  "checks": {
    "database": { "status": "up", "latencyMs": 12 }
  }
}
03

Authentication and access

Protected web routes use NextAuth sessions and roles. Public API keys are not exposed in the current release, so never place assumed credentials or fabricated keys in a client.

  • ADMIN for management and CMS operations
  • CLIENT and MEMBER for account and project capabilities
  • STUDENT for academy-related access
04

Errors and rate limits

Clients should inspect the HTTP status and response body. Retry temporary failures with backoff and correct the input for validation errors.

  • 400: invalid or incomplete input
  • 401/403: insufficient session or role
  • 429: endpoint rate limit exceeded
  • 500/503: service or dependency failure; avoid unbounded retries

The estimate endpoint accepts up to 10 requests per IP per minute.

Did this guide miss your question?
Send your technical context to our team and we will help identify the right path.