Skip to main content

HTTP Status Codes

The API uses standard HTTP status codes. The following are commonly used status codes and their meanings:
Status CodeMeaningDescription
200OKRequest was successful
201CreatedResource was successfully created
204No ContentRequest was successful but there is no content
400Bad RequestThere is an error in the request (invalid parameter, etc.)
401UnauthorizedAuthentication information is invalid or missing
403ForbiddenNo access permission
404Not FoundThe requested resource does not exist
422Unprocessable EntityThe request format is correct but semantically incorrect
429Too Many RequestsRate limit exceeded
500Internal Server ErrorServer internal error

Error Response Format

When an error occurs, the API returns a JSON response in the following format:
{
  "statusCode": 400,
  "errorId": "validation_exception",
  "message": "Validation failed",
  "errorDetails": [
    {
      "property": "email",
      "constraints": {
        "isEmail": "email must be an email"
      }
    }
  ]
}

Response Fields

FieldTypeDescription
statusCodeintegerHTTP status code
errorIdstringError identifier
messagestringBrief description of the error
errorDetailsarrayDetailed error information (if available)

Common Errors

Authentication Error (401)

{
  "statusCode": 401,
  "errorId": "unauthorized",
  "message": "Unauthorized"
}
Cause: API key is invalid or missing

Permission Error (403)

{
  "statusCode": 403,
  "errorId": "forbidden",
  "message": "Forbidden"
}
Cause: No permission for the requested operation

Validation Error (422)

{
  "statusCode": 422,
  "errorId": "validation_exception",
  "message": "Validation failed",
  "errorDetails": [
    {
      "property": "name",
      "constraints": {
        "minLength": "name must be longer than or equal to 1 characters"
      }
    }
  ]
}
Cause: Request parameters do not meet validation rules

Error Handling Best Practices

  1. Properly handle all HTTP status codes
  2. Implement retry logic especially for 429 (rate limit) errors
  3. Log error messages to help diagnose problems
  4. Display user-friendly error messages to users
  5. Do not include sensitive information in error messages
Last modified on April 22, 2026