Skip to content
Last updated

PERS Error Handling

Error Response Structure

PERS API uses structured error responses for consistent error handling across all endpoints. All errors follow the same format with security-filtered messages and correlation IDs for support.

Why Structured Errors?

  • Consistency: All errors follow a uniform structure and categorization
  • Security: Sensitive system details are filtered out; only safe messages are returned
  • Traceability: Every error includes a correlation ID for support and debugging
  • Programmatic Handling: Structured format enables reliable error processing

API Error Format

All PERS API errors return structured JSON responses following RFC 7807 (Problem Details for HTTP APIs):

{
  "status": 404,
  "title": "Resource Not Found",
  "detail": "User with ID 12345 could not be found",
  "message": "User with ID 12345 could not be found",
  "code": "USER_NOT_FOUND",
  "category": "DOMAIN_RULE",
  "timestamp": "2025-11-01T10:30:00.000Z",
  "correlationId": "req-abc-123",
  "userMessage": "The requested user could not be found",
  "retryable": false
}

Error Response Fields

FieldTypeDescription
statusnumberHTTP status code
titlestringHuman-readable error summary
detailstringSpecific error explanation
messagestringError message (usually same as detail)
codestringError code for programmatic handling
categorystringError classification (VALIDATION, SECURITY, etc.)
timestampstringISO timestamp when error occurred (optional)
correlationIdstringRequest correlation ID for support (optional)
userMessagestringUser-friendly message safe for display (optional)
retryablebooleanWhether operation can be retried

TypeScript Support

For TypeScript applications, import error types from the shared library:

import type { StructuredError, ErrorCategory } from '@explorins/pers-shared';

Error Categories & HTTP Status Mapping

CategoryHTTP StatusDescriptionRetryable
VALIDATION400Invalid request data or formatNo
SECURITY403Authentication/authorizationNo
DOMAIN_RULE422Business logic validation errorsNo
RATE_LIMIT429Request rate limitingYes
INFRASTRUCTURE503External service failuresYes

Error Handling Examples

Example Error Response

Authentication Error (401)

{
  "status": 401,
  "title": "Authentication Required",
  "detail": "Valid authentication credentials are required",
  "message": "Authentication required",
  "code": "AUTHENTICATION_REQUIRED",
  "category": "SECURITY",
  "timestamp": "2025-11-01T10:30:00.000Z",
  "correlationId": "req-abc-123",
  "userMessage": "Please log in to access this resource",
  "retryable": false
}

Validation Error (400)

{
  "status": 400,
  "title": "Validation Error",
  "detail": "The email field is required",
  "message": "The email field is required",
  "code": "REQUIRED_FIELD",
  "category": "VALIDATION",
  "timestamp": "2025-11-01T10:30:00.000Z",
  "correlationId": "req-def-456",
  "details": {
    "field": "email",
    "rejectedValue": null
  },
  "retryable": false
}

Client-Side Error Handling

// Example: Handling API errors in JavaScript/TypeScript
async function callAPI() {
  try {
    const response = await fetch('/api/users', {
      method: 'POST',
      headers: {
        'Authorization': 'Bearer your-token',
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({ name: 'John' })
    });
    
    if (!response.ok) {
      const error = await response.json();
      
      // Handle different error categories
      if (error.category === 'SECURITY') {
        // Redirect to login
        window.location.href = '/login';
      } else if (error.category === 'VALIDATION') {
        // Show validation errors to user
        showValidationError(error.details);
      } else {
        // Show generic error message
        showErrorMessage(error.userMessage || error.message);
      }
      return;
    }
    
    const data = await response.json();
    // Handle success response
  } catch (networkError) {
    // Handle network errors
    showErrorMessage('Network error. Please try again.');
  }
}

Security Features

  • System error details are never exposed to API consumers
  • Every error includes a correlation ID for traceability
  • All errors are logged with full context for debugging
  • Consistent error categorization across all domains

For further details, see the Authentication Guide and Developer Resources.