Watchlist Enrolment

Watchlists are the monitored items Defentry watches for breaches and dark-web exposure: emails, phones, IBANs, passports, driver's licenses, and credit cards.

The account's SSN (national ID) is also monitored — but it works differently: it is not a managed watchlist (there are no add/list/delete routes). It is set once on the account and then monitored automatically. See SSN (national ID) below.

There are two ways to manage them, and choosing correctly is the crux of the integration.

CRM token vs app token

Route shape	Token	Acts as	Confirmation
/api/v1/account/{id}/…-watchlist	CRM	Your service account, on behalf of the user	Admin-managed — no end-user click
/api/v1/…-watchlist (no account id)	App	The end user themselves	Subject to end-user confirmation where applicable

For backend-driven enrolment, prefer the CRM {id} routes: you add items for any account you administer without requiring the user to be online. Use the app routes when the user is operating their own account in your UI (see End-user access to obtain an app token).

Email

CRM token

POST /api/v1/account/{account_id}/email-watchlist
Authorization: Bearer {crm_token}

{ "email": "john.doe@example.com" }

App token

POST /api/v1/email-watchlist
Authorization: Bearer {app_token}

{ "email": "john.doe@example.com" }

Read, inspect leaks, and remove:

GET    /api/v1/account/{account_id}/email-watchlist
GET    /api/v1/account/{account_id}/email-watchlist/leaks
DELETE /api/v1/account/{account_id}/email-watchlist/{emailId}

App-token equivalents:

GET    /api/v1/email-watchlist
GET    /api/v1/email-watchlist/leaks
DELETE /api/v1/email-watchlist/{emailId}

Resend a pending end-user confirmation email:

POST /api/v1/resend/watchlist-email-confirmation

Phone

CRM token

POST /api/v1/account/{account_id}/phone-watchlist
Authorization: Bearer {crm_token}

{ "phone": "+46701234567" }

App token

POST /api/v1/phone-watchlist
Authorization: Bearer {app_token}

{ "phone": "+46701234567" }

Optional SMS verification (only when you need account-level phone confirmation):

POST /api/v1/account/{account_id}/phone-watchlist/send-verification-code
POST /api/v1/account/{account_id}/phone-watchlist/confirm

Read / leaks / delete follow the email pattern under phone-watchlist (/api/v1/account/{account_id}/phone-watchlist/{phoneId} to remove). App-token routes mirror them without the account id.

IBAN

POST   /api/v1/account/{account_id}/iban-watchlist
GET    /api/v1/account/{account_id}/iban-watchlist
GET    /api/v1/account/{account_id}/iban-watchlist/leaks
DELETE /api/v1/account/{account_id}/iban-watchlist/{ibanId}

App token: POST/GET /api/v1/iban-watchlist, GET /api/v1/iban-watchlist/leaks, DELETE /api/v1/iban-watchlist/{ibanId}.

Passport

POST   /api/v1/account/{account_id}/passport-watchlist
GET    /api/v1/account/{account_id}/passport-watchlist
PATCH  /api/v1/account/{account_id}/passport-watchlist/{passportId}
DELETE /api/v1/account/{account_id}/passport-watchlist/{passportId}

App token: POST/GET /api/v1/passport-watchlist, plus PATCH/DELETE /api/v1/passport-watchlist/{passportId}.

Driver's license

POST   /api/v1/account/{account_id}/drivers-license-watchlist
GET    /api/v1/account/{account_id}/drivers-license-watchlist
DELETE /api/v1/account/{account_id}/drivers-license-watchlist/{licenseId}

App token: POST/GET /api/v1/drivers-license-watchlist, DELETE /api/v1/drivers-license-watchlist/{licenseId}.

SSN (national ID)

SSN is not a managed watchlist

Unlike the items above, an SSN has no add / list / delete watchlist routes. The SSN is monitored automatically once it is set on the account. It can be set two ways: by your backend when the account is created (POST /api/v1/account, CRM token), or by the end user after creation via an electronic ID flow (app token). There is no CRM route to add or change an SSN after creation. You can only toggle monitoring of an existing SSN via PATCH /api/v1/account/{account_id}/ssn-monitoring/activate and /deactivate.

Credit cards

CRM routes use the account id; cards added this way skip the end-user verification step:

POST   /api/v1/account/{account_id}/credit-card
GET    /api/v1/account/{account_id}/credit-cards
GET    /api/v1/account/{account_id}/credit-card/{creditCardId}
DELETE /api/v1/account/{account_id}/credit-card/{creditCardId}

App-token routes, including the user-facing verification flow:

POST   /api/v1/credit-card
GET    /api/v1/credit-cards
POST   /api/v1/credit-cards/verify
GET    /api/v1/credit-card/leaks
GET    /api/v1/credit-card/{creditCardId}
DELETE /api/v1/credit-card/{creditCardId}

Next steps

• End-user access (SSO) — when the user manages their own items
• Alarms — what fires when a monitored item is exposed