> ## 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.

# Changelog

> Product updates and API improvements.

<Update
  label="September 7, 2026"
  description="Easier radar reconciliation with cursor pagination"
  tags={["API", "Radars", "Pagination"]}
  rss={{
title: "Easier radar reconciliation with cursor pagination",
description: "List Radars now makes it easier to page through and reconcile your radar inventory."
}}
>
  ## Easier radar reconciliation

  You can now page through your radars and more easily reconcile the inventory in
  your system with TAMradar after an interrupted sync, missed creation response,
  or integration incident. Follow the cursor through every page to complete the
  traversal. If radars may have been created while you were paging, start a fresh
  request without a cursor to pick them up.

  `GET /v1/radars` now returns radars in deterministic newest-first pages:

  * Use `limit` to request 1–500 radars per page; the default remains 50.
  * When `has_more` is `true`, pass `next_cursor` back as the `cursor` query parameter.
  * Use `created_since` with an ISO 8601 timestamp and timezone to include radars created at or after that time.
  * `count` is the number of radars on the current page, not a total count.

  ### Behavior changes

  * The maximum `limit` is now 500. Higher values return `400`.
  * Unknown query parameters now return `400` instead of being ignored. This catches mistakes such as sending `next_cursor` as the parameter name instead of `cursor`.
  * `radar_status=inactive` now includes every radar that is not active.

  Keep all filters unchanged while following a cursor. To discover radars created
  during a traversal, start a fresh request without a cursor. `created_since`
  filters creation time only, not later status or configuration changes.

  This endpoint returns radar records. Use [`GET /v1/updates`](/api-reference/poll-updates)
  to retrieve radar findings and failures.

  See [List Radars](/api-reference/list-radars).
</Update>

<Update
  label="August 26, 2026"
  description="Social engagement monitoring window extended to 5 days"
  tags={["API", "Webhooks", "Social Engagements"]}
  rss={{
title: "Social engagement monitoring window extended to 5 days",
description: "Contact and company social engagement radars now monitor each post for up to 5 days with no engagement cap."
}}
>
  ## Social engagement monitoring window extended to 5 days

  `contact_social_engagements` and `company_social_engagements` radars now:

  * Monitor each post for up to 5 days for net-new engagement activity (previously 48 hours)
  * Per-post engagement cap raised from 200 to unlimited — all engagements within the 5-day window are captured
  * Use your `updates_since` timestamp (or radar creation time if not set) as the cutoff for eligible posts. To receive historic or backdated activity, set `updates_since` to the earliest date you care about.

  See [Contact Social Engagements](/webhooks/contact/social-engagements) and [Company Social Engagements](/webhooks/company/social-engagements).
</Update>

<Update
  label="August 18, 2026"
  description="More precise job-title filtering"
  tags={["API", "Radars", "Filtering"]}
  rss={{
title: "Build more precise job-title filters",
description: "Company radars now support full Boolean job-title expressions and exact whole-title matching."
}}
>
  ## Build more precise job-title filters

  Company radar `job_titles` filters now support:

  * Combining required groups with `AND`, such as `("sales operations") AND (manager OR VP)`.
  * Standalone and grouped exclusions with `NOT`.
  * `EXACT("Sales Operations Manager")` for case-insensitive, normalized whole-title equality.
  * Nested expressions with standard `NOT`, `AND`, then `OR` precedence.

  Existing filters remain compatible. Quoted phrases continue to use containment, while `EXACT("...")` is optional new syntax for whole-title matching.

  Malformed expressions return an actionable `job_titles` error. Bulk submissions remain asynchronous, with malformed expressions recorded as item-level failures.

  See [Filtering and Personas](/guides/filtering-and-personas) and [Create Company Radar](/api-reference/create-company-radar).
</Update>

<Update
  label="August 17, 2026"
  description="Contact identifier validation improvements"
  tags={["API", "Radars", "Contacts"]}
  rss={{
title: "More reliable contact identifiers and duplicate errors",
description: "Contact job-change radars now reject shared inboxes and non-person LinkedIn URLs, and duplicate responses identify the matching field."
}}
>
  ## Contact radar validation changes

  New `contact_job_changes` radar requests now:

  * Reject role-based, shared, and placeholder email addresses.
  * Accept only LinkedIn person profiles under `/in/`; company, school, and legacy `/pub/` URLs are rejected.
  * Report duplicate matches as `identifiers.email` or `identifiers.profile_url` in `409` responses.

  These changes apply to new single and bulk radar creation requests. Existing radars are unaffected.

  See [Create Contact Radar](/api-reference/create-contact-radar) and [Error Handling](/guides/error-handling).
</Update>

<Update
  label="August 16, 2026"
  description="Synchronous bulk radar deactivation"
  tags={["API", "Radars", "Bulk"]}
  rss={{
title: "Deactivate up to 500 radars in one request",
description: "The new bulk DELETE endpoint returns an ordered final outcome for every requested radar."
}}
>
  ## Bulk deactivate radars

  ### Features

  * Send 1–500 unique radar IDs to `DELETE /v1/radars/bulk`.
  * Receive final ordered success or failure details for every ID in one synchronous response.
  * Reuse the same per-item success and error contract as single-radar deactivation.

  ### Behavior

  * Monthly radars enter their paid grace period; update-based radars deactivate immediately.
  * Expected item failures do not prevent valid items from being deactivated.
  * Bulk create and bulk delete share the bulk rate-limit budget.

  See [Bulk Deactivate Radars](/api-reference/delete-bulk-radars).
</Update>

<Update
  label="August 14, 2026"
  description="Radar creation improvements"
  tags={["API", "Radars"]}
  rss={{
title: "Choose how far back a new radar should scan with updates_since",
description: "New radars can now include an updates_since timestamp to control the source-event boundary for initial processing."
}}
>
  ## Set a radar start point with `updates_since`

  ### Features

  * Create company, contact, industry, and bulk radars with an optional `updates_since` timestamp.
  * Make matching source events at or after that timestamp eligible for delivery.
  * Inspect the stored setting in radar responses as a normalized UTC timestamp or `null`.

  ### Compatibility

  * `include_historical` remains accepted, but `updates_since` is the field to use for new integrations.
  * Historical results may continue arriving during the first 24 hours after radar creation.

  See [Quickstart](/quickstart), [Getting Started](/getting-started), and [Bulk Create](/guides/bulk-create-guide).
</Update>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.