Skip to main content

Customer

Represents an individual or company undergoing checks.

Case

A container for all checks and documents related to a single customer investigation. API interactions work primarily through Cases.

Check

A specific verification process, like a sanctions screening or address verification. One check would be one “alert” or “hit” - not multiple. For each check within a KYB or EDD, such as UBOs or web presence, a new check is created.

Document

Supporting files, such as identity documents or proofs of address. Not required. A sanctions screening might solely rely on details provided in the Customer object, or the Customer might have supporting documentation such as a driver’s license.

​
Relationships

The diagram below illustrates how these models are interconnected. A Customer can have multiple Cases, each Case can have multiple Checks, and Documents can be associated with any of the other three models. Documents can be associated with a Case, Check, or Customer, but only one at a time. Each association serves different purposes:
  • Linking to a Case: General document storage for the entire case workflow. Recommended starting point.
  • Linking to a Check: More precise. Isolated work for the AI agent and faster processing. Useful is check types such as Proof of Address.
  • Linking to a Customer: Documents persist across cases. Useful when running multiple cases against the same customer - documents persist across cases.
When uploading a document, you must provide exactly one of case_id, check_id, or customer_id to link it appropriately.