Concepts & data model

This page explains how CryptoComply's core objects fit together so the rest of the API reference makes sense. KYC (Know Your Customer) and AML (Anti-Money Laundering) are the compliance workflows these objects support.

The shape of the API

Almost every endpoint is scoped to an organization and nested under /api/orgs/{org_pk}/. The org_pk is the organization id you get from GET /api/orgs/. A handful of account-level endpoints (/api/orgs/, /api/auth/..., /api/choices/...) sit outside that prefix.

Organization (tenant)
├── Members ── Roles ── Permissions      who can do what
├── Profiles (counterparties)            the people/entities you track
│   ├── Attachments + Submissions        documents and intake-form data
│   ├── Linked blockchain addresses      wallets tied to this profile
│   ├── Related parties                  profile-to-profile relationships
│   └── Notes
├── Profile Groups                       collections of profiles, shared settings
├── Blockchain Addresses (wallets)       on-chain addresses you screen
│   ├── Screenings + risk changes        results over time
│   ├── Exposure risk thresholds         when exposure becomes an alert
│   └── Notes / Tags
├── Alerts                               raised when risk changes
│   └── Inquiries (RFIs)                 requests for information
├── Intake Forms ── Invitations          collect data from counterparties
├── Notifications + preferences          how members are told about events
└── API keys (provider credentials)      Chainalysis, TRM, Open Sanctions, …

Core objects

Object	What it is
Organization	Your tenant. All data is isolated to one organization; an API key only reaches organizations its user belongs to.
Member	A user's membership in an organization, with an assigned role.
Role / Permission	Roles bundle permissions. CryptoComply ships system roles and lets you define organization-custom roles. Permissions are grouped by category (see GET /api/orgs/{org_pk}/permissions/). The model is configurable, not a fixed set of three tiers.
Profile	A counterparty you track — a person or entity. Profiles hold identity data, attachments, linked wallets, and a risk rating.
Profile Group	A collection of profiles that can share risk thresholds and settings.
Blockchain Address	An on-chain address ("wallet") you screen for sanctions exposure and illicit-activity risk. Marketing materials call these "wallets"; the API calls them blockchain addresses.
Alert	Raised when a screened object's risk changes — for example, a new sanctions hit or rising exposure. Alerts move through statuses (Open → Under Review → Escalated → Closed).
Inquiry (RFI)	A Request for Information attached to an alert or profile, used to chase down missing facts.
Intake Form / Invitation / Submission	Forms you send to counterparties to collect KYC data; an invitation is one send, a submission is the returned data.

Multi-tenancy and isolation

CryptoComply is multi-tenant. Every organization-scoped endpoint enforces that the authenticated key belongs to the organization in the path, and only returns rows owned by that organization. Practical consequences:

• Always pass the correct org_pk. Using another organization's id returns 404, not another tenant's data.
• A key cannot reach across organizations. To work in two organizations, use a key (and membership) in each.
• Object ids are not guessable cross-tenant — even a valid id from another organization returns 404.

Roles carry into the API

An API key inherits the role of the member who created it, and the key's access level (read-only vs full-access) narrows it further. A read-only key can never write, even if its member's role could. See Authentication & API keys.

What's next

• Authentication & API keys — keys, access levels, and provider credentials.
• Quickstart — make a call against these objects.
• Full REST reference — every endpoint and field.