Skip to main content

​
Errors

The Capital Check In API uses conventional HTTP response codes to indicate the success or failure of an API request.

​
HTTP Status Codes

CodeDescription
200OK - Request successful
201Created - Resource created successfully
400Bad Request - Invalid request syntax
401Unauthorized - Authentication required
403Forbidden - Insufficient permissions
404Not Found - Resource not found
422Unprocessable Entity - Validation error
429Too Many Requests - Rate limit exceeded
500Internal Server Error - Server error

​
Error Response Format

All error responses follow a consistent format: 
{
  "error": "error_code",
  "message": "Human-readable error message",
  "details": {
    "field": "Additional error details"
  }
}

​
Common Error Codes

​
Authentication Errors

{
  "error": "invalid_credentials",
  "message": "Invalid email or password"
}

{
  "error": "token_expired",
  "message": "Access token has expired"
}

​
Validation Errors

{
  "error": "validation_error",
  "message": "Validation failed",
  "details": {
    "email": "Invalid email format",
    "password": "Password must be at least 8 characters"
  }
}

​
Resource Errors

{
  "error": "resource_not_found",
  "message": "Collaborator not found"
}

{
  "error": "resource_already_exists",
  "message": "User with this email already exists"
}

​
Error Handling Best Practices

  • Always check the HTTP status code first
  • Parse the error response for detailed information
  • Implement proper error logging
  • Handle rate limiting with exponential backoff
  • Provide user-friendly error messages
  • Retry transient errors (5xx status codes)