Compliance API
The API an integrator or back-office reads server-side to get a user's KYC / compliance status. Assetera is the responsible party for KYC/AML. Mostly planned.
The Compliance API lets your backend read a user's KYC / compliance status server-side. The status is separate from the login account: someone can be authenticated yet not verified. Assetera is the responsible party for KYC/AML, so this API is the projection you read to decide what a user may do, rather than running verification yourself.
WIP, updated during compliance-api development
Almost everything on this page is planned. Concrete endpoints, field names, status values, and levels are not yet published. Treat the table and shape below as illustrative and do not code against them yet. The auth model (Keycloak bearer JWT validated against JWKS) is the confirmed part.
What it returns
A status projection, not the underlying verification data. Conceptually:
| Field (illustrative) | Meaning |
|---|---|
| KYC status | Where the user is: not started, pending, verified, or rejected. |
| Level / tier | How far verification went (for example basic vs enhanced due diligence). |
| Verification date | When the current status was last established. |
The API is a resource server: it validates a bearer JWT against Assetera Identity's JWKS (issuer, audience, signature), then answers for the identified user. See Authentication.
How your backend uses it
Gate sensitive actions on the returned status server-side. A verified login is not a verified user; read compliance status before allowing anything that requires it.
Marketplace API
The Marketplace / Trading REST API: base URL, bearer auth, and the known resources (tokens, token detail, candles). Evolving; OpenAPI forthcoming.
Real-time (SSE)
The planned real-time subscription service. Integrators subscribe over Server-Sent Events (SSE) to live updates such as order and trade updates and notifications. Planned.