Skip to main content

​
Overview

The MTB Backend API uses standard HTTP status codes to indicate the success or failure of API requests. Error responses include detailed information to help you diagnose and resolve issues.

​
HTTP Status Codes

The API returns the following HTTP status codes:
Status CodeDescription
200OK - Request succeeded
201Created - Resource successfully created
204No Content - Request succeeded with no response body
400Bad Request - Invalid request parameters or malformed syntax
401Unauthorized - Authentication required or invalid credentials
403Forbidden - Authenticated but lacking permissions
404Not Found - Requested resource does not exist
429Too Many Requests - Rate limit exceeded
500Internal Server Error - Server encountered an unexpected error
503Service Unavailable - Server temporarily unavailable

​
Error Response Format

All error responses follow a consistent JSON structure provided by Strapi: 
{
  "data": null,
  "error": {
    "status": 400,
    "name": "ValidationError",
    "message": "Invalid request parameters",
    "details": {
      "errors": [
        {
          "path": ["email"],
          "message": "Email is required",
          "name": "ValidationError"
        }
      ]
    }
  }
}

​
Response Fields

​
data
null
Always null for error responses
​
error
object
Container for error information
​
status
number
HTTP status code
​
name
string
Error type identifier (e.g., ValidationError, NotFoundError)
​
message
string
Human-readable error description
​
details
object
Additional error details, structure varies by error type

​
Common Errors

Cause: Invalid or missing required fields in the request body or query parameters.Example:
{
  "error": {
    "status": 400,
    "name": "ValidationError",
    "message": "Missing required field",
    "details": {
      "errors": [
        {
          "path": ["title"],
          "message": "Title is required"
        }
      ]
    }
  }
}
Solution: Verify that all required fields are included and properly formatted.
Cause: Missing or invalid authentication token.Example:
{
  "error": {
    "status": 401,
    "name": "UnauthorizedError",
    "message": "Missing or invalid credentials"
  }
}
Solution: Ensure you include a valid JWT token in the Authorization header:
Authorization: Bearer YOUR_JWT_TOKEN
Cause: Authenticated user lacks permission to access the resource or perform the action.Example:
{
  "error": {
    "status": 403,
    "name": "ForbiddenError",
    "message": "Forbidden access"
  }
}
Solution: Verify that your user account has the necessary permissions for this operation.
Cause: The requested resource does not exist or the endpoint URL is incorrect.Example:
{
  "error": {
    "status": 404,
    "name": "NotFoundError",
    "message": "Not Found"
  }
}
Solution: Check the resource ID and endpoint URL for typos.
Cause: Too many requests sent in a given timeframe.Example:
{
  "error": {
    "status": 429,
    "name": "RateLimitError",
    "message": "Too many requests, please try again later"
  }
}
Solution: Implement exponential backoff and retry logic in your client application.
Cause: Unexpected server-side error.Example:
{
  "error": {
    "status": 500,
    "name": "InternalServerError",
    "message": "An internal server error occurred"
  }
}
Solution: If the error persists, contact the API administrators with the request details.

​
Best Practices

Always implement proper error handling in your client application:
  • Check status codes before processing responses
  • Log error details for debugging
  • Provide user-friendly error messages
  • Implement retry logic for transient errors (429, 503)
The details field structure may vary depending on the error type. Always check for its presence before accessing nested properties.

Build docs developers (and LLMs) love

Get started for freeTalk to us