This page gives a high-level view of TAMradar billing and lifecycle behavior. For model-specific implementation details:Documentation Index
Fetch the complete documentation index at: https://docs.tamradar.com/llms.txt
Use this file to discover all available pages before exploring further.
Overview
TAMradar uses a USD credit balance system to bill for radar usage. Two pricing models exist, and which one applies to a radar depends on your account configuration per radar type.Pricing Models
Monthly Subscription
- Charge at creation — balance is deducted when the radar is first created.
- Recurring charge — deducted automatically every 30 days while the radar is active.
next_charge_atin the API response shows the next billing date. - Refund on setup failure — if the radar fails during initial setup (missing prerequisites, source inaccessible), the creation charge is automatically reversed and you receive a
radar_failurewebhook withrefund_amount_usd > 0. - User cancellation — radar transitions to
inactive. For monthly subscription, service can continue until the current billing period ends.
Update-Based
- No charge at creation —
next_charge_atisnull. Nothing is deducted when the radar is set up. - Charged per update found — balance is deducted each time TAMradar finds and approves a new update for your radar (a new hire, job change, funding round, etc.).
- No refund on setup failure — if the radar fails during setup, you receive a
radar_failurewebhook withrefund_amount_usd: 0(nothing was charged, so nothing to refund). - Auto-reactivation on top-up — if a radar was deactivated due to insufficient funds, it automatically reactivates when a new payment is added to your account. No manual action needed.
Radar States
radar_status in public API responses is intentionally simplified to two values:
Public radar_status | Meaning |
|---|---|
active | Running normally. Balance is deducted per the pricing model. |
inactive | Any non-active lifecycle state (cancelled, failed, insufficient funds, or grace-period state). |
radar_status(active/inactive)radar_failurepayload fields likefailure_reason,message, andrefund_amount_usd
Monitoring Balance Events
Webhook Notifications
Your application receivesradar_failure webhook events whenever a radar is deactivated due to a billing or setup issue.
Monthly subscription — insufficient funds during renewal
Radar is deactivated when the 30-day charge cannot be covered. No refund (the original creation charge was for time already used).
refund_amount_usd is always 0 because nothing was charged at creation.
Failure Reasons
failure_reason | Description | Refund |
|---|---|---|
missing_prerequisites | Required public data not found (e.g. no LinkedIn profile, no public RSS) | Monthly sub: yes. Update-based: no. |
source_inaccessible | Data source exists but cannot be accessed | Monthly sub: yes. Update-based: no. |
setup_failure | Generic failure during radar initialisation | Monthly sub: yes. Update-based: no. |
insufficient_funds | Radar deactivated — balance too low for renewal charge | No refund |
Bulk Endpoint — Async Outcomes
POST /v1/radars/bulk is asynchronous. The submission endpoint returns 202 with bulk_id, and item outcomes are emitted later.
For balance-related failures in bulk:
- the affected item ends in a failure state during async processing
- the failure appears in:
GET /v1/radars/bulk/:bulk_iditem results, and- webhook delivery (
radar_failurefor item-level failures, plus finalbulk_completed)
Best Practices
- Monitor balance — poll
GET /v1/accountforbalance_remaining_usdand alert before it hits zero. - Handle
radar_failurewebhooks — persistfailure_reasonandrefund_amount_usdfor reconciliation. - Update-based: top up proactively — radars auto-reactivate on top-up, but there’s a gap while they’re inactive. Schedule automatic top-ups to avoid missed updates.
- Monthly subscription: budget for renewals — check
next_charge_aton your active radars and ensure balance covers the next 30 days. - Bulk retries are workflow-based — top up balance, then resubmit the failed items from your async bulk status/webhook outcomes.