Skip to main content

How TAMradar delivers updates

TAMradar supports two ways to receive radar findings:
  • Webhooks (push) — TAMradar POSTs events to your webhook_url in real-time. Set webhook_url when creating a radar to enable this.
  • Polling (pull) — Fetch findings on demand via GET /v1/updates. Works for all radars, including those created without a webhook_url.
Both delivery methods use the same payload format documented below.

Payload Libraries by Category

Company Payloads

Contact Payloads

Industry Payloads

Setting Up Webhook Delivery (optional)

If you want real-time push delivery, set up an HTTPS endpoint:
  1. Create an HTTPS endpoint on your server that can receive POST requests
  2. Pass webhook_url when creating your radar
  3. Ensure your endpoint returns a 2xx status code to acknowledge receipt
No webhook? Skip webhook_url entirely to create a poll-only radar. Findings are always available via GET /v1/updates regardless.

Webhook Delivery & Reliability

Timeouts

TAMradar waits 10 seconds for your endpoint to respond. If no response is received within that window, the attempt is treated as a failure and retried.

Retries & backoff

If your endpoint returns a non-2xx status (including 5xx) or times out, TAMradar retries up to 3 times with exponential backoff: After 4 total attempts (1 initial + 3 retries), delivery is permanently abandoned.

Data is never lost

Push delivery failure does not mean data loss. Every event is written to our internal store before delivery is attempted — findings are always retrievable via GET /v1/updates, regardless of webhook delivery outcome. Use polling as a fallback if your endpoint experiences downtime.

Deduplication

On retry, the same update_id is resent. Use update_id as your idempotency key to deduplicate events safely.

Webhook Payload Format

All webhook payloads follow this structure:

Base Fields

Update Types

Per-item bulk webhook events

Before the final bulk_completed, each item delivers its own webhook as it finishes:
  • radar_created — item was created successfully. Includes code: 201, message: "Radar created successfully", completed_at, and a full data block matching the single-radar creation response.
  • radar_failure — item failed validation, conflict, or billing. Includes completed_at, code, errors[], and message matching the sync API error shape. Also emits discovered_at (same value as completed_at) for backwards compatibility — prefer completed_at going forward.
radar_created example:
radar_failure example:

Bulk update_id semantics

For bulk_completed events, two ID levels can appear and they serve different purposes:
  • Top-level update_id: idempotency key for the whole bulk_completed webhook event.
  • Per-item radars[].update_id: correlation key for each item’s earlier radar_created or radar_failure event.
Store both when you consume bulk webhooks:
  • Deduplicate bulk_completed retries by top-level update_id.
  • Correlate each radars[] item back to its individual item event with radars[].update_id.
bulk_completed payloads use a batch envelope with completed_at, summary, and radars[]. Each entry in radars[] is the verbatim payload from that item’s per-item webhook:

Radar Types

Radar Failure Notifications

When a radar fails setup or is deactivated due to billing, you’ll receive a radar_failure notification:
When setup fails, the same radar_failure shape is used with a different code and refund value:

Failure Reasons

Identify the failure type from code and message. The errors[].reason field contains the machine-readable reason key.

Best Practices for Webhook Handling

  1. Respond Quickly: Return a 2xx status code immediately, then process asynchronously
  2. Implement Retry Logic: Be prepared to handle the same event multiple times
  3. Verify Signatures: Check webhook signatures to validate authenticity (documentation coming soon)
  4. Track Failure Events: Monitor radar_failure to handle billing/setup problems quickly
  5. Handle Null Fields: Some fields like record_id may be null for certain event types

Testing Your Webhook

Quick test

Trigger a sample payload to your endpoint:
The test event is fire-and-forget, with no retries or signatures, and uses the same payload format you’ll receive in production. Need help? Contact our team