Skip to main content

What is TAMradar?

TAMradar monitors companies, contacts, and industries by tracking their online activity and sending real-time notifications when something changes.

Core Concepts

  • Radars — A monitor you configure. You define what to track (a company, a person, or an industry keyword) and what signal to look for (job openings, new hires, funding rounds, etc.).
  • Webhooks — How you receive events. TAMradar sends a POST request to your URL when a radar fires.
  • Polling — Alternative to webhooks. Use GET /v1/updates to pull events on your schedule.
  • Balance — Radars cost balance to create and run. Check yours before creating radars.

Radar Types

TAMradar has three categories of radars, each with its own creation endpoint: Company radar types: company_job_openings, company_new_hires, company_promotions, company_reviews, company_mentions, company_social_posts, company_social_posts_cxo, company_social_engagements Contact radar types: contact_job_changes, contact_social_posts, contact_social_engagements Industry radar types: industry_mentions, industry_funding_rounds, industry_new_companies, industry_job_openings

Step 1: Authentication

Every request requires your API key in the x-api-key header:
A 401 means your key is missing or invalid. A 200 means you’re authenticated.

Step 2: Check Your Balance

Before creating radars, confirm you have sufficient balance:
Response:
Add ?month=YYYY-MM to get stats for a specific month (defaults to current UTC month).

Step 3: Create a Radar

webhook_url is optional. Omit it to create a poll-only radar. Updates are available via GET /v1/updates. Add it when you want TAMradar to push events to your server in real-time.

Choose a data starting point with updates_since

updates_since is optional. Use it when you want to pull qualifying historical data or ensure that eligible source events start from a date you choose.
  • Supply an RFC 3339 timestamp with a timezone, such as 2026-07-01T09:00:00-04:00. TAMradar stores and returns the equivalent UTC instant.
  • The value must represent now or a past instant and may be at most five calendar years old. A five-second server tolerance exists only for clock skew; it does not enable future scheduling.
  • Omit the field to store updates_since: null. The radar’s created_at is then the effective cutoff.
  • Historical processing is asynchronous. Qualifying findings may continue arriving during the first 24 hours before the radar settles into its normal recent-update schedule.
The stored response value for that input is 2026-07-01T13:00:00.000Z.
For new-hire and promotion radars, source dates are evaluated at calendar-month precision even though the exact submitted timestamp is preserved in the radar response. During initial engagement history, the parent post’s publication time sets eligibility; recurring engagement delivery uses when TAMradar first discovers the engagement.
include_historical is deprecated. It remains accepted for compatibility but has no effect on delivery behavior. Use updates_since instead.

Company Radar

Monitor a company for job openings, with optional department and seniority filters:
Filterable company types: company_job_openings, company_new_hires, company_promotions, company_social_posts_cxo Valid departments: Engineering, Sales, Marketing, Finance, Human Resources, Product Management, Operations, Customer Success, Design, Legal, Information Technology, Leadership, Research, Accounting, Administrative, Business Development, Consulting, Education, Manufacturing, Media and Communication, Project Management, Purchasing, Quality Assurance, Real Estate, Support Valid seniorities: Owner, CXO, Vice President, Director, Manager, Senior, Entry, Training, Partner Response (201):
Save the radar_id. You’ll need it later.

Contact Radar

Track a specific person’s job changes or social activity:
Rules:
  • contact_job_changes — requires domain + at least one of: profile_url, email, full_name
  • contact_social_posts / contact_social_engagements — requires profile_url (LinkedIn, X, or Twitter only)
  • For contact_job_changes, email must identify an individual; role-based, shared, and placeholder addresses are rejected
  • For contact_job_changes, profile_url must be a LinkedIn person profile (linkedin.com/in/...); company, school, and legacy /pub/ URLs are rejected
  • Within the same company and radar type, duplicate matching uses email or the normalized LinkedIn profile URL; full_name is not a duplicate key

Industry Radar

Track a keyword or theme across companies and news:
Rules:
  • industry_mentions and industry_job_openingskeyword is required (min 3 chars)
  • industry_funding_rounds and industry_new_companies — no keyword needed
  • countries — optional, max 5 country codes

Step 4: List and Inspect Radars

Query parameters: Response (200):
Note: Filter fields (departments, seniorities, job_titles) and identifier fields (profile_url, email, full_name, keyword) are returned flat at the top level of each radar object. They are only present when set.

Step 5: Receive Events

When a radar fires, TAMradar POSTs an event to your webhook_url.

Webhook Payload Structure

All webhook events follow this envelope:
  • data — radar context (always present, same fields regardless of type)
  • content — the actual finding (structure varies by radar_type)

Your Webhook Must

  1. Accept POST with a JSON body
  2. Return any 2xx status code within a reasonable timeout
  3. Handle duplicates — use update_id as an idempotency key

Polling Alternative

If you prefer pull over push, use GET /v1/updates:
Query parameters: radar_id (comma-sep, max 10), radar_type (comma-sep), domain (comma-sep, max 10), since (ISO 8601), cursor, limit (1–100, default 25), update_type (radar_finding | radar_failure, default: radar_finding) updates_since and the polling query parameter since serve different purposes. Radar updates_since is the permanent eligibility boundary selected at creation. GET /v1/updates?since= only filters TAMradar updates that have already been created; it does not change the radar. Response shape:
Pass next_cursor as cursor in the next request to paginate. has_more: false means you’ve reached the end.

Step 6: Bulk Create Radars

Submit a bulk request for asynchronous processing (up to 1000 items):
  • webhook_url is required at the envelope level for async bulk
  • Items can mix company, contact, and industry types
  • Max 1000 items, max 1MB request body
  • Item-level validation and creation happen asynchronously after submission
Submission response (202 Accepted):
Save bulk_id, then poll for status:
The status endpoint returns:
  • status: "processing" while items are still running
  • status: "completed" when all items are terminal
  • Per-item outcomes in radars[] with item_index mapping back to the input order
  • radars[].update_id as the per-item correlation key (radar_created / radar_failure)
For webhook idempotency/correlation in async bulk:
  • Use top-level update_id on bulk_completed to deduplicate the batch event itself
  • Use radars[].update_id inside bulk_completed to map each item back to its individual item event

Step 7: Deactivate a Radar

Response (200):
Deactivation is a soft delete. The radar record is retained for history.

Error Responses

All errors follow the same structure:
Use error_id when contacting support. It traces the exact request in our logs.

Key Constraints