Skip to main content
This page gives a high-level view of TAMradar billing and lifecycle behavior. For model-specific implementation details:

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_at in 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_failure webhook with refund_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 creationnext_charge_at is null. 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_failure webhook with refund_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: Internal lifecycle enums are implementation details and are not part of the public API contract. For external handling, use:
  • radar_status (active / inactive)
  • radar_failure payload fields: code, message, and refund_amount_usd

Monitoring Balance Events

Webhook Notifications

Your application receives radar_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).
Monthly subscription — setup failure (with refund) Radar failed during initial setup. Creation charge is reversed automatically.
Update-based — setup failure (no refund) Same webhook shape, but refund_amount_usd is always 0 because nothing was charged at creation.

Failure Reasons

Failure type is identified by code and message in the radar_failure payload.

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_id item results, and
    • webhook delivery (radar_failure for item-level failures, plus final bulk_completed)
Treat bulk as a queued workflow rather than a synchronous per-item response.

Best Practices

  1. Monitor balance — poll GET /v1/account for balance_remaining_usd and alert before it hits zero.
  2. Handle radar_failure webhooks — persist code, message, and refund_amount_usd for reconciliation.
  3. 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.
  4. Monthly subscription: budget for renewals — check next_charge_at on your active radars and ensure balance covers the next 30 days.
  5. Bulk retries are workflow-based — top up balance, then resubmit the failed items from your async bulk status/webhook outcomes.