Skip to main content
This page explains the shared notification model and the v1 API URL examples. For the full LENS (v2) watchlist surface — CRUD, members, subscriptions, event types, dashboard, and bulk acknowledge — see Watchlists in the v2 API.

Concepts

TIC uses three concepts for change notifications. Keeping them straight makes the rest of this page easier to follow. A webhook is one type of notification trigger — specifically, one whose destination is an HTTPS URL. Email and SMS triggers carry a narrower summary; only webhook triggers receive the full event payload.
Use webhook triggers when you need the full event data. Use email/SMS when a human just needs to be alerted that something changed.

Creating a notification trigger

Before a trigger becomes active it must be confirmed. Confirmation behavior depends on the trigger type:

Webhook trigger (URL)

Auto-confirms when the destination URL responds with a successful HTTP status code to the initial confirmation request. Retries up to three times.

Email trigger

An email is sent to the destination address with a confirmation link. The trigger activates once the recipient clicks it.

SMS trigger

A text message is sent to the destination mobile number with a confirmation link. The trigger activates once the recipient clicks it.

Example — creating a webhook trigger

The example below adds a webhook trigger to watchlist 6 that reacts to changes in address, annual reports, intelligence, representatives, and status.
cURL
Response
A confirmation notification is then POSTed to the destination URL using the same payload format shown below.
Webhook payload

Testing a webhook trigger

You can test webhook triggers to verify your endpoint handles the payload correctly.
cURL
The test POST carries an array of sample events. Since 2025-05-02, every event in the array includes the source of the change.
Test payload

Event types

The watchListMemberEventType field identifies what changed. Valid values: