Overview
The TAMradar API uses standard HTTP status codes and a consistent error response format.Error Response Envelope (400, 401, 403, 404, 409, 429, 500, 503)
status: Always “error” for error responsescode: HTTP status codemessage: Human-readable error descriptionerrors: Array of field-level errors (field+reason). May be empty ([]) for some server-side failures.timestamp: When the error occurrederror_id: Unique identifier for error tracking
Error Response Formats
Error Format Example (400)
Server Error Format (500)
Error Types
| Status | Description | Common Causes |
|---|---|---|
| 400 | Bad Request | Missing required fields, invalid format |
| 402 | Payment Required | Insufficient balance |
| 401 | Unauthorized | Missing or invalid API key |
| 403 | Forbidden | Valid API key but insufficient permissions |
| 404 | Not Found | Invalid radar ID or resource not found |
| 409 | Conflict | Duplicate radar (includes existing radar ID for direct access) |
| 429 | Rate Limit Exceeded | Per-minute budget exhausted or per-second burst limit exceeded |
| 500 | Internal Server Error | Application bugs, unexpected code issues |
| 503 | Service Unavailable | Database outages, external service downtime |
Common Error Examples
Validation Error (400)
Insufficient Balance Error (402)
Authentication Error (401)
Permission Error (403)
Duplicate Resource Error (409)
When creating a radar that already exists, the API returns the existing radar’s ID so you can fetch it directly usingGET /v1/radars/{radar_id}.
Different Radar Types Have Specific Error Messages:
Company Radars:Using the Returned Radar ID:
Extract theradar_id from the reason message and fetch the existing radar:
Rate Limiting
Rate limits are enforced per API key. When rate limited, you’ll receive:POST /v1/radars/bulk, the 429 message is Rate limit exceeded — wait and retry. with reason: "minute".
Server Error (500)
Service Unavailable (503)
Best Practices
- Handle Consistent Structure: Parse the
errorsarray for all non-2xx responses. - Log Error IDs: Store
error_idfor support requests and debugging. - Handle Rate Limits: Implement exponential backoff when rate limited
- Validate Input: Pre-validate requests to minimize validation errors
- Check Balance: Monitor account balance to avoid insufficient balance errors
Error Recovery
For server errors (500):- Implement retry logic with exponential backoff
- Maximum 3 retry attempts recommended
- Add jitter to prevent thundering herd
- Implement retry logic with exponential backoff
- Maximum 5 retry attempts recommended (infrastructure usually recovers)
- Start with longer delays (30s, 60s, 120s…)
- Check our status page for ongoing incidents
- Log the specific validation failures
- Fix the request payload based on the
reasonfield - Resubmit with corrected data
- Verify API key is correctly formatted
- Check API key is included in
x-api-keyheader - Ensure API key is active and valid
- Check current balance via account dashboard
- Top up balance as needed
- Retry the operation
Support
If you need help resolving errors:- Note the
error_id - Check our status page
- Contact support at support@tamradar.com
- Error ID
- Timestamp
- Request details (endpoint, method)
- Steps to reproduce