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
Common Error Examples
Validation Error (400)
updates_since Validation Errors (400)
updates_since must be an RFC 3339 timestamp with an explicit timezone. It must
represent now or a past instant and cannot be more than five calendar years old.
The API allows up to five seconds of clock skew, but this is not future
scheduling.
Timezone missing:
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:
Readerrors[0].conflicting_radar_id and fetch the existing radar:
Platform accounts: duplicate creation can be enabled. For platform use cases
(e.g. managing radars on behalf of your own customers), duplicate radar creation
can be enabled account-wide on request — contact support. When enabled:
- Creating the same radar definition again returns
201with a new, independentradar_idinstead of409— every successful create is a new radar. - TAMradar does not deduplicate create requests for your account. You own retry
idempotency: store each returned
radar_id, and don’t blind-retry timeouts — a request that timed out may still have succeeded and created a radar. - Each radar bills independently, including duplicates.
- This applies to single and bulk creation alike.
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