MuleSoft Error Handling Standard
A production-ready global error handler standard providing consistency, operational clarity, and consumer-friendly responses across System, Process, and Experience APIs.
1. The Missing Taxonomy Problem
Inconsistent error handling across hundreds of APIs creates massive operational friction. Without a standardized framework, API consumers receive unpredictable error JSON structures, support teams lack the critical correlation context needed to triage issues across layered architectures, and developers waste time explicitly rewriting retry logic and HTTP status mappings for every new project.
2. Foundational Design Principles
- Canonical Context: Every error, whether an HTTP timeout or a DataWeave crash, produces the exact same deterministic JSON structure containing the
correlationId,errorCode, and an array of granulardetails. - Dual-View Paradigm: External API responses are heavily sanitized to mask internal infrastructure endpoints and stack traces, while internal log appenders capture maximal technical payloads for rapid Tier-2 troubleshooting.
- Don't Repeat Yourself (DRY): A single global error handler catches 95% of standard HTTP, connectivity, and routing exceptions automatically, removing massive XML boilerplate from individual integration flows.
- HTTP Standards Alignment: A strict mapping engine converts abstract domain models into RFC-compliant HTTP status codes (e.g., mapping a
BUSINESSfailure to 422 Unprocessable Entity, bypassing naive 500s).
Standardized Code Catalog
The taxonomy classifies errors strictly to accelerate incident response without demanding log parsing skills from Layer-1 support teams. Custom applications format errors as [PREFIX]-[HTTP_STATUS]-[UNIQUE_ID].
- VAL-400-001 (Schema Validation)
- BUS-422-001 (Business Rule Flaw)
- AUT-401-002 (Invalid Token)
- DCT-504-001 (Gateway Timeout)
- SYS-500-001 (Execution Panic)
- UNX-500-001 (Unhandled Default)
Sanitized Payload Example
Notice how the downstreamSystem identity is redacted in this simulated 504 Timeout out of caution, but the Support Reference remains explicitly bound to the Correlation ID for tracing.
{
"timestamp": "2023-11-20T08:40:01.112Z",
"correlationId": "4f1c9800-8773-11ee-b9d1-0242ac120002",
"applicationName": "sap-customer-system-api",
"apiLayer": "System",
"error": {
"code": "DCT-504-001",
"category": "DOWNSTREAM_TIMEOUT",
"message": "Gateway Timeout. An underlying system failed to respond.",
"userMessage": "We are currently experiencing delays processing your request.",
"downstreamSystem": null,
"retryable": true,
"supportReference": "CORR-4f1c9800-8773-11ee-b9d1-0242ac120002",
"details": []
}
}