Overview
The Mighty Networks API uses standard HTTP status codes to indicate the success or failure of requests. Proper error handling is essential for building robust integrations.HTTP Status Codes
| Status Code | Meaning | Description |
|---|---|---|
| 200 | OK | Request succeeded |
| 201 | Created | Resource created successfully |
| 204 | No Content | Request succeeded with no response body |
| 400 | Bad Request | Invalid parameters or malformed request |
| 401 | Unauthorized | Missing or invalid API token |
| 403 | Forbidden | Valid token but insufficient permissions |
| 404 | Not Found | Resource doesn’t exist |
| 409 | Conflict | Resource conflict (e.g., duplicate) |
| 422 | Unprocessable Entity | Validation error |
| 429 | Too Many Requests | Rate limit exceeded |
| 500 | Internal Server Error | Server-side error |
| 502 | Bad Gateway | Temporary server issue |
| 503 | Service Unavailable | Service temporarily down |
Error Response Format
All errors return a JSON response with consistent structure:Example Error Responses
Authentication Error (401)
Not Found Error (404)
Validation Error (422)
Common Error Types
1. Authentication Errors (401)
Causes:- Missing
Authorizationheader - Invalid or expired API token
- Malformed Bearer token
2. Permission Errors (403)
Causes:- Token lacks required scopes/permissions
- Attempting to access resources outside your network
- Admin-only operation with non-admin token
3. Resource Not Found (404)
Causes:- Invalid resource ID
- Resource was deleted
- Incorrect network ID
- Typo in endpoint URL
4. Validation Errors (422)
Causes:- Invalid field values
- Missing required fields
- Data format errors
5. Rate Limit Errors (429)
Causes:- Exceeded requests per minute limit
- Too many requests in short time
Error Handling Patterns
Basic Error Handling
Comprehensive Error Handler
Custom Error Classes
Retry Logic
Python Error Handling
Basic Pattern
Custom Exception Classes
Retry with Backoff
Best Practices
- Always Check Status Codes - Don’t assume requests succeed
- Parse Error Messages - Extract meaningful information from error responses
- Implement Retries - Retry transient errors (5xx, 429)
- Don’t Retry 4xx Errors - Client errors won’t succeed on retry (except 429)
- Log Errors - Keep detailed error logs for debugging
- Handle Gracefully - Provide user-friendly error messages
- Monitor Errors - Track error rates to identify issues
- Validate Input - Catch errors before making API calls