Home/REST Track/Error Mapping & Problem Details

Error Mapping & Problem Details

Learn to map carrier error responses to your domain, and use RFC 9457 Problem Details for consistent error handling.

The Error Zoo

Every carrier has a different error format. Some return { error: 'message' }, others { errors: [{ code, detail }] }, and some return HTML error pages on 500s. Your integration layer must normalize all of these into a consistent internal format.

RFC 9457 Problem Details

Problem Details (application/problem+json) is a standard format: { type, title, status, detail, instance }. Map carrier errors to this format at the integration boundary. Your upstream services get a consistent shape regardless of which carrier caused the error.
Carrier Reality

USPS returns errors in XML with codes like -2147219401. You need a mapping table to convert these to meaningful Problem Details responses for your consumers.

Error Categories

Classify errors into: retryable (503, 429, timeout), permanent (400, 404, 422), and ambiguous (500, timeout on POST). Each category needs a different handling strategy. Retryable errors go to the retry queue. Permanent errors fail fast. Ambiguous errors need investigation before retry.

Practice Drills

Classify errors into three categories: (503, 429), (400, 404), and (500, timeout on POST).

What is the RFC 9457 Problem Details format used for?