Skip to main content
Use this guide after an interrupted sync, a missed creation response, or a webhook outage. Each endpoint answers a different question: You do not need to send a list of radar IDs to retrieve your account’s inventory or updates. The examples below cover all radar types.

​
Reconcile your radar inventory

Start with a request for up to 500 radars. Omit radar_status to include both active and inactive radars, and omit created_since to include older radars.
For each page:
  1. Read the radar records from data.
  2. Insert or update each local record using radar_id as its key. Save the returned radar_status, including inactive.
  3. If has_more is true, request the next page with the returned next_cursor as cursor. Repeat until has_more is false.
Keep any filters unchanged on every page. Treat cursors as opaque: do not parse, construct, or modify them. The response’s count is the number of radars on that page, not the total on your account. If you supplied your own record ID in custom_fields when creating a radar, use it to connect the returned radar to the record in your system. Keep radar_id as the key for the radar itself.
created_since filters creation time only. It does not find older radars whose status changed. To refresh their status, list them again without that filter.
A traversal is not a frozen snapshot. Radars created after the first page may not appear in the remaining pages, and statuses can change during the scan. Start a fresh traversal to pick up later changes. Do not treat an interrupted scan as a complete inventory or remove local records just because they have not appeared yet.

​
Recover missed updates

Use polling alongside webhooks, or on its own. Both delivery paths use update_id, so you can store each update once even if it arrives through both. For the first sync, choose a since timestamp for the period you need, or omit it to retrieve all retained updates. For later syncs, start about one minute before the bookmark from your last completed sync. For example, if your saved bookmark is 2026-05-01T08:00:00Z, start at 07:59:00Z:
By default, GET /v1/updates returns radar_finding only. The example requests both findings and radar_failure updates from the feed. Use this loop:
  1. Keep since and all filters fixed for the entire traversal.
  2. Store each item in updates, deduplicating by update_id. Repeated items must not trigger the same downstream action twice.
  3. While has_more is true, send next_cursor as cursor with the same since and filters.
  4. Only after every page is successfully stored, save the highest discovered_at seen as the new bookmark. If no updates were returned, keep the existing bookmark.
Keep the bookmark separate from the pagination cursor. Start each new sync without a cursor. If you use separate filtered syncs, keep a bookmark for each filter set. If you change filters to include updates you have not stored, choose a since value that covers the history you need.
Do not advance the bookmark after only the first page or after an interrupted traversal. Results are newest first, so doing so could skip the remaining older updates. Restart from the previous completed bookmark and deduplicate.
discovered_at is the time an update was added to your feed. The one-minute overlap reduces the risk of missing an update being added while you poll; it is not a guarantee. Updates are retained for about 60 days. Poll well within that window and keep your own copy for longer history. Polling cannot recover updates that have already been purged. The polling since parameter filters updates already in your feed. It does not change a radar’s updates_since, which controls historical source-event eligibility. See Poll Updates for the full contract.

​
Reconcile bulk creation

A 202 Accepted response means the submission was queued. It does not mean every radar was created.
  1. Save the returned bulk_id and your submitted items immediately.
  2. Poll GET /v1/radars/bulk/{bulk_id} until the top-level status is completed.
  3. Match each item in radars to your submitted item using item_index, the zero-based position within that batch. Use custom_fields for your own record mapping when supplied.
  4. For an item with status: "success", store data.radar_id. For an item with status: "error", store its code, message, and errors for review. Also save error_id when present so you can include it in a support request.
completed means every item has a final outcome, including failures. Finished items have an update_id that matches the item’s webhook outcome, so polling and webhook handling can share the same deduplication key. A failed attempt to create an item in a bulk submission also uses update_type: "radar_failure". That creation outcome is returned through bulk status and configured webhooks, not GET /v1/updates. It is separate from the radar_failure updates available in the polling feed. See the Bulk Create Guide for submission examples and Get Bulk Create Status for per-item response fields.

​
Resume after an interruption

For other errors, follow Error Handling. See Authentication & Rate Limits for read budgets and retry headers.