API Overview
How Klarefi's public API is organized for hosted intake, processing pilots, and review-ready case files
The Klarefi API lets customer systems create hosted intake sessions, submit documents when Processing API access is enabled, read current case state, receive signed webhooks, and erase document-derived data.
All examples use:
https://api.klarefi.comPilot deployments may expose a Convex site URL instead. Use the base URL shown in the dashboard for your workspace.
Versioning
Public endpoints live under /api/v1. Additive response fields may appear over
time. Integrations should ignore unknown fields and use documented IDs,
statuses, and event names for control flow.
Integration Model
Hosted Intake is the default integration. Klarefi owns the applicant-facing
flow. Create a session, redirect the applicant to signed_url, then consume
the case through webhooks or case reads.
Processing API is an advanced pilot surface. Use it only when Klarefi has enabled direct document submission for your workspace and your system already owns the applicant-facing experience.
Both surfaces produce the same case. Klarefi prepares the case for review; it does not decide the regulated outcome.
Marketing pages call the end-to-end product "the agent"; in API terms, start with Hosted Intake. "Cited extraction" is the evidence guarantee on the facts Klarefi returns, not a separate integration mode.
Common Conventions
- Requests and responses are JSON unless an endpoint says otherwise.
- API keys are sent with
Authorization: Bearer sk_live_...orAuthorization: Bearer sk_test_.... POST /api/v1/sessionsrequires anidempotency_keyin the JSON body or anIdempotency-Keyheader.POST /api/v1/processis available only when Processing API access is enabled for your workspace.- Authenticated success responses include
X-RateLimit-*headers. - Error responses use the shared
{ "error": { ... } }envelope.