Developer portal
/api/v1. All responses are wrapped in a data envelope; list endpoints add a pagination object./api/v1/assetsPublicList and search the asset catalogue.
/api/v1/assets/{id}PublicFetch a single canonical asset record.
/api/v1/assets/{id}/assessments/latestPublicLatest assessment for an asset. Returns data: null with status NOT_SCREENED when no assessment exists.
/api/v1/assets/{id}/assessmentsPublicFull immutable assessment history, including activity scopes.
/api/v1/screeningsBearer tokenQueue a durable screening job. Responds 202 with a job identifier. Requires an Idempotency-Key header.
/api/v1/screenings/{jobId}Bearer tokenOperational state of a screening job — queued, processing, succeeded, failed or cancelled.
/api/v1/methodologiesPublicPublished methodology versions, criteria and citations.
/api/v1/healthPublicService health. Returns HTTP 503 when the service is not fully configured.
curl "https://<your-deployment>/api/v1/assets?q=ETH&page=1&pageSize=25"
{
"data": [
{
"id": "…",
"providerId": "…",
"symbol": "ETH",
"name": "…",
"assetClass": "crypto",
"network": "…",
"contractAddress": null,
"status": "NOT_SCREENED"
}
],
"pagination": { "page": 1, "pageSize": 25, "total": 1 }
}curl -X POST "https://<your-deployment>/api/v1/screenings" \
-H "Authorization: Bearer <supabase-access-token>" \
-H "Idempotency-Key: 6f0c1c2e-…" \
-H "Content-Type: application/json" \
-d '{"assetId":"<asset-id>","scope":"asset"}'
HTTP/1.1 202 Accepted
{ "data": { "id": "<job-id>", "state": "queued" } }Supply a stable Idempotency-Key per logical request. Repeating a request with the same key returns the existing job instead of queuing a duplicate.
{
"error": {
"code": "ASSET_NOT_FOUND",
"message": "No asset exists with that identifier.",
"requestId": "req_…"
}
}401 — missing or expired credentials.403 — authenticated but not permitted, including admin routes.404 — unknown asset, job or route.429 — rate limit or quota exceeded for the key.503 — the service is not configured or a dependency is down.Read endpoints are public. Screening requests, watchlists and key management require a bearer token.
Browser sessions use your Supabase session automatically. Server-to-server integrations use an API key issued from the key management page.
Keys are stored hashed. The full key value is shown once, at creation, and cannot be retrieved again.
Job states — queued, processing, succeeded, failed, cancelled — are operational and are never assessment statuses.
Rate limits and quotas are enforced per key and reported by the API. Current limits for your keys are shown on the key management page.
Cache responses where you can. Assessments change only when a screening job completes.