Error Handling · API2Cart
Unified Error Handling Across eCommerce APIs
70+ platforms, one error format. API2Cart normalizes platform-specific errors into consistent return codes with clear messages.
Error handling across multiple platforms means juggling a different error format for every single one.
API2Cart provides one unified error system. Every response includes a consistent return_code and return_message. Write your error handling once.
How Error Handling Works in API2Cart
- return_code: numeric code in every response (0 = success, >0 = error)
- return_message: human-readable description of the error
- Error categories: authentication, validation, not found, rate limit, server
- Every request carries a unique request_id for troubleshooting
Example request
// Success
{ "return_code": 0, "result": { ... } }
// Error (unified across all platforms)
{ "return_code": 112, "return_message": "Product not found" }
Use Cases for Error Handling
Robust Integration
One error handler for every platform — less code, fewer bugs.
User-Facing Messages
Consistent error messages regardless of the backend platform.
Monitoring & Alerting
Unified error codes power dashboards, alerts, and SLA tracking.
Debugging
request_id plus the original platform error for fast root-cause analysis.
Frequently asked questions
The things people ask before using Error Handling.
What does a typical error response look like?
{"return_code": 112, "return_message": "Product not found"}
Can I see the original platform error?
Yes — available in the extended response details.
Which errors are transient?
Rate limit and server errors (5xx) usually are; auth/validation errors are permanent.
How do I integrate this with my monitoring?
Use return_code for classification, request_id for correlation.
One error format. 70+ platforms. Write your error handling once.
For the full list of return codes and their meanings, see the Response Status Codes reference.
What does a typical error response look like?
A response with "return_code": 112 and "return_message": "Product not found".
Can I see the original platform error?
Yes — available in the extended response details.
Which errors are transient?
Rate limit and server errors (5xx) usually are; auth/validation errors are permanent.
How do I integrate this with my monitoring?
Use return_code for classification, request_id for correlation.
