Assetera DocsCompliance API
The customer-scoped API for onboarding status, MetaKYC SDK sessions, and registered-wallet status.
The Compliance API provides a narrow self-service surface for the signed-in customer. A partner BFF forwards the customer's Assetera access token; the browser does not call the API with a bearer token.
Customer-facing surface
| Method | Path | Purpose |
|---|---|---|
GET | /api/kyc/me/status | Read the caller's current onboarding status. |
GET | /api/kyc/me/profile | Read the caller's permitted profile projection. |
POST | /api/kyc/session | Start or resume a MetaKYC SDK session for the caller. |
GET | /api/wallet/challenge | Create a one-time wallet-ownership challenge. |
POST | /api/wallet | Register a wallet after the customer signs the challenge. |
GET | /api/wallet | List the caller's registered wallets and current status. |
GET | /api/wallet/:address | Read one caller-owned wallet. |
These routes are subject-scoped. They do not accept an arbitrary user ID for reading another customer's record.
Read onboarding status server-side
The status response separates authentication from onboarding. A valid login does not by itself enable a regulated action. Use the current API response for UX, and rely on the destination API to enforce the action again server-side.
Start a MetaKYC session
POST /api/kyc/session resolves the user from the bearer token. In a direct MetaKYC SDK integration, use
the same Keycloak sub as externalRefId. See KYC integration.
Return only the short-lived SDK token and applicant reference needed by the browser component. Never return the customer's general Assetera access token or the partner's MetaKYC keys.
Wallet registration
Wallet registration is a customer-controlled challenge and response flow. The API verifies the signed challenge, records the wallet for that customer, and returns a coarse status used by the frontend. Only a wallet in an allowed state can be used for regulated actions.
Public partner documentation intentionally does not describe screening vendors, rule logic, thresholds, review queues, or monitoring procedures. Integrate against the status contract and customer-facing error handling supplied for your tenant.
Security requirements
- Forward the current user's token, never a machine token, to customer-scoped routes.
- Do not accept
sub, email, or applicant ID from an untrusted browser as authorization input. - Keep customer profile responses minimal and avoid copying them into analytics or application logs.
- Treat unavailable compliance dependencies as fail-closed for regulated writes.
- Use the tenant-specific API contract supplied during onboarding for exact payloads and enumerations.