Every PureWL DPP API response is wrapped in a common envelope with a header and a body.

Response envelope

The response body is a JSON object with a header object and a body object:

HTTP status codes

Application error codes

Failures also carry an application code in header.response_code (and in header.code, where the endpoint returns it), with header.message explaining why. Text in braces, such as {uuid}, is filled in with the actual value.
Codes are defined per service, and the same number can mean different things in each — for example 10200 is a missing user in Dark Web Monitoring but a missing profile in Data Broker Opt-Out. Always read a code together with the service you called.User Management and authentication use four-digit codes (998, 1001–1008); Dark Web Monitoring and Data Broker Opt-Out use five-digit codes.

User Management and authentication

Dark Web Monitoring

General

Partner account

Users and monitored assets

Lookups

Data Broker Opt-Out

General

Partner

Profile

Broker

Partner broker

Country and region

Email templates

PoA branding

Email tracking

Broker scan

Retry and backoff guidance

Follow these practices when handling failed requests:
  • Treat any HTTP 5xx response as potentially transient — retry with exponential backoff.
  • Treat HTTP 429 (rate limited) as transient — see Rate Limits for backoff guidance.
  • Do not blindly retry 4xx client errors (e.g., invalid parameters, auth failures) without first correcting the request — retrying an invalid request will fail the same way every time.
  • If your Access Token has expired, get a new one with the refresh grant type described on the Authentication page before retrying.

Next steps

Rate Limits

Learn how 429 responses fit into this error model.

Authentication

Get and refresh the Access Token every call needs.

API Reference overview

Return to the full endpoint reference map.