API Reference

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.com

Pilot 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.

Default API flow

Common Conventions

  • Requests and responses are JSON unless an endpoint says otherwise.
  • API keys are sent with Authorization: Bearer sk_live_... or Authorization: Bearer sk_test_....
  • POST /api/v1/sessions requires an idempotency_key in the JSON body or an Idempotency-Key header.
  • POST /api/v1/process is 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.

On this page