Error Handling

All Fangate API responses follow a consistent structure. Understanding this format is essential for robust integrations.

Standard Response Format

Success Response

{
  "success": true,
  "errors_message": null,
  "data": { ... }
}

Field	Type	Description
success	boolean	Always true for successful requests
errors_message	string | null	null on success
data	object	Response payload (varies by endpoint)

Error Response

{
  "success": false,
  "errors_message": "Error description or validation message",
  "data": null
}

Field	Type	Description
success	boolean	Always false for errors
errors_message	string	Human-readable error description
data	null	Always null on error

HTTP Status Codes

Code	Meaning
200	OK — Request succeeded
201	Created — Resource created successfully
204	No Content — Success with no body (e.g. logout)
400	Bad Request — Invalid parameters or validation failed
401	Unauthorized — Missing or invalid token
403	Forbidden — Valid token but insufficient permissions
404	Not Found — Resource doesn't exist
422	Unprocessable Entity — Business logic validation failed
429	Too Many Requests — Rate limit exceeded
500	Internal Server Error — Server-side error

Common Error Scenarios

400 Bad Request

• Invalid request body (missing required fields, wrong types)
• Validation errors (e.g. email format, password length)
• Business rule violations (e.g. age < 18)

Example:

{
  "success": false,
  "errors_message": "The email has already been taken.",
  "data": null
}

401 Unauthorized

• Missing Authorization header
• Invalid or expired token
• Token revoked (e.g. after logout)

Example:

{
  "success": false,
  "errors_message": "Unauthenticated.",
  "data": null
}

403 Forbidden

• Authenticated user lacks permission for the resource
• e.g. Accessing another user's product

Example:

{
  "success": false,
  "errors_message": "Forbidden",
  "data": null
}

404 Not Found

• Resource ID does not exist
• Product, user, or media not found

Example:

{
  "success": false,
  "errors_message": "Product not found",
  "data": null
}

Validation Errors

When multiple validation errors occur, errors_message may contain a JSON string or concatenated messages. Check the response structure for your specific endpoint.

Best Practices

1. Always check success before processing data
2. Handle errors_message — display or log for debugging
3. Implement retry logic for 429 and 500 with exponential backoff
4. Validate input client-side to reduce 400 responses
5. Store tokens securely — avoid 401 from token exposure