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

What is the RFC 9457 Problem Details format used for?

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