Skip to main content

API request lifecycle

Every request to TaruviBase passes through the same checks, in this order:

  1. Route. The site address selects your site, and the path selects the app and resource.
  2. Authenticate. TaruviBase reads the session token, API key, or JWT and identifies the caller.
  3. Validate. The path, query parameters, and body are checked against the operation.
  4. Authorize. The caller's roles and the app's access policies decide whether the action is allowed.
  5. Respond. The result returns in a standard JSON envelope.

Response envelope​

Successful responses include status, message, and data. List responses also include total:

{
"status": "success",
"message": "Data retrieved successfully",
"data": [],
"total": 0
}

Errors include a code and message, and may add detail or field-level errors:

{
"status": "error",
"message": "Validation failed",
"code": "VALIDATION_ERROR",
"errors": {"title": ["This field is required."]}
}

Debug in order​

Failures at different steps can look alike, so check them in the same order the request travels:

  1. Address and path — TARUVI_SITE_URL, the app slug, the method, and the trailing slash on the path.
  2. Credential — a 401 means it is missing, invalid, expired, or from a different site.
  3. Request body and parameters — a 400 with VALIDATION_ERROR lists the fields to fix.
  4. Permissions — a 403 means the caller is known but not allowed; check roles and access policies.
  5. The operation itself — for a 5xx response, note the time and the operation, retry reads, and read the current state before retrying a write.

See Authentication and authorization for the credential types.