Errors

When working with the Manage API of FoxNose CMS, it’s important to understand how to handle errors that may occur during API requests. Errors are categorized into standard HTTP status codes and may include additional information to help you diagnose and resolve issues.

Error Status Codes

The API may return the following error status codes:

  • Name
    400 Bad Request
    Description

    The request was invalid or cannot be served. This is often due to validation errors or incorrect data in the request.

  • Name
    401 Unauthorized
    Description

    Authentication is required and has failed or has not yet been provided.

  • Name
    403 Forbidden
    Description

    The request was valid, but you do not have the necessary permissions to perform the action.

  • Name
    404 Not Found
    Description

    The requested entity could not be found.

  • Name
    405 Method Not Allowed
    Description

    The HTTP method used is not supported for this endpoint.

  • Name
    429 Too Many Requests
    Description

    The user has sent too many requests in a given amount of time (“rate limiting”).

Common Error Structure

For errors, the API returns a response with the following structure:

  • Name
    message
    Type
    string
    Description

    A human-readable description of the error.

  • Name
    error_code
    Type
    string
    Description

    A unique identifier for the type of error, useful for programmatic handling.

  • Name
    detail
    Type
    object null
    Description

    Additional details about the error. It can be null or contain an object with more information.

Error object example

{
    "message": "Description of the error",
    "error_code": "error_code_identifier",
    "detail": null // or an object with additional information
}

Types of 400 Errors

Errors with a 400 status code are divided into two main types: validation errors and endpoint-specific errors.

1. Validation Errors

These errors occur when the data sent in the request does not meet the validation requirements of the API.

In this case:

  • "error_code": "validation_error"
  • "detail": An array of objects, each describing a specific validation error.

Validation error example

{
  "message": "Invalid data was provided",
  "error_code": "validation_error",
  "detail": [
    {
      "type": "string_too_short",
      "loc": ["name"],
      "msg": "String should have at least 1 character",
      "input": "",
      "ctx": {
        "min_length": 1
      }
    }
  ]
}

Explanation of detail Fields

  • Name
    type
    Type
    string
    Description

    The type of validation error. This should always be a string describing the type of error, like value_error or type_error.

  • Name
    loc
    Type
    array
    Description

    The location path to the field where the error occurred. This is a list of path components (e.g., ["field", "subfield"]) and should always be an array.

  • Name
    msg
    Type
    string
    Description

    A message describing the error, always provided as a string.

  • Name
    input
    Type
    any
    Description

    The value that caused the error. This can be of any type, as it reflects the erroneous input.

  • Name
    ctx
    Type
    object null
    Description

    Contextual information about the error (e.g., expected minimum length). This is typically an object with specific keys depending on the error, but can also be null if there’s no context.

Validation error example

{
  "message": "Invalid data was provided",
  "error_code": "validation_error",
  "detail": [
    {
      "type": "value_error",
      "loc": ["region"],
      "msg": "Value error, Invalid region",
      "input": "antarctic-west",
      "ctx": {
        "error": "Invalid region"
      }
    }
  ]
}

2. Endpoint-Specific Errors

These errors are related to business logic or constraints specific to certain API endpoints. They have unique error codes and messages.

  • "error_code": A unique code describing the specific problem.
  • "detail": Always null.

Validation error example

{
  "message": "Production environment cannot be deleted",
  "error_code": "production_environment_cannot_be_deleted",
  "detail": null
}

Examples

const axios = require('axios');

// Sample request to handle validation errors
axios.post('https://api.foxnose.net/endpoint/', {})
.then(response => {
console.log (response.data);

})
.catch(error => {
if (error.response && error.response.status === 400) {
const errorData = error.response.data;
if (errorData.error_code === 'validation_error') {
errorData.detail.forEach(err => {
const field = err.loc[0];
const message = err.msg;
console.error(`Error in field '${field}': ${message}`);
});
} else {
console.error(`Error: ${errorData.message}`);
}
} else {
// Handle other status codes
console.error(error.message);
}
});

Recommendations

  • Check the Status Code: Use the HTTP status code to determine the type of error.
  • Use error_code: Rely on the error_code field for programmatic error handling and to display appropriate messages to the user.
  • Handle Validation Errors: For validation_error, parse the detail field to provide specific feedback on what went wrong with the input data.
  • Avoid Using message for Logic: Do not rely on the message text for programmatic decisions, as it may change.

Was this page helpful?