verzi.health Log inGet a key
✓TypeScript SDK · @verzihealth/sdk

The warranted record, typed into your build.

A TypeScript client for the Verzi Health API, generated from the committed /v1 OpenAPI contract. Warrants, fee schedules, coding edits, provider standing, and the archive, with the auth and as-of plumbing done for you. For RCM, billing, and healthtech developers.

Request access See the code v0.1 · early access

Package @verzihealth/sdk · auth X-API-Key · contract /v1 · 264 paths

What it is

Three doors to one room. The SDK is the builder door.

The /v1 API is the single source of truth. The SDK and the MCP server are derived from it, never hand-maintained in parallel. The SDK is for the engineer wiring the warrant into a billing system, a claim scrubber, or an RCM product: deterministic, typed, in your build.

API
Any integrator, over HTTP
The source of truth. Every endpoint takes as_of; every envelope returns meta.as_of. →
SDKyou are here
A developer writing code
Deterministic, typed access, generated from the same /v1 contract. For billing and RCM vendors.
MCP
An agent, tool-calling
Claude, Cursor, or a vendor's AI calls the warrant as a tool and reads the receipt. →

The principle

Generated, never hand-written. It cannot drift.

The one architectural rule behind all three surfaces: one source, three surfaces. The SDK's types are produced from the committed /v1 OpenAPI spec, and a CI drift guard fails the build if the generated types go stale against the contract. A spec change regenerates the SDK. Hand-editing is the one thing that breaks alignment, so there is none.

1One contract
The committed /v1 spec: 264 paths, 268 operations. What flows to the SDK is the contract, not the implementation.
2Zero drift
Types are generated with openapi-typescript; the client is openapi-fetch. CI regenerates and fails if stale.
3Thin by design
The SDK adds only the X-API-Key header and an optional as_of default. No fat features, no parallel logic.

Quickstart

Install, authenticate, ask.

One client, your key, and the same question every payer meeting asks: what was true on the date of service?

install · early access
npm install @verzihealth/sdk
warrant.ts
// The warrant join for one code, provider, and date of service.
import { createVerziClient } from "@verzihealth/sdk";

const verzi = createVerziClient({ apiKey: process.env.VERZI_API_KEY! });

const { data, error } = await verzi.GET("/rules/warrant", {
  params: { query: { hcpcs: "E0601", as_of: "2024-01-15", npi: "1234567890", state: "UT" } },
});

// One block per warrant: standing, fee, edits, documentation.
// Each block carries its own fact and its own receipt:
// version_id · file_id · sha256 you can replay, or an honest gap.

as_of is canonical; dos is the alias. Billers think in date-of-service, so the warrant endpoints accept both. For a warrant they are the same date. The full endpoint reference lives in the docs.

The surface

The warrant subset, plus the whole catalog.

Every /v1 path is callable through the client. These are the ones a claims workflow starts with.

GET /rules/warrant · hcpcs, as_of, npi, …
The warrant join. One block per warrant (standing, fee, edits, documentation), each with its fact and receipt or an honest gap.
GET /rules/warrant/changes · hcpcs, from_dos, to_dos
Did policy move since the claim's date of service? The any_change headline an appeal starts from.
GET /rules/dmepos/fee · /rules/ncci/mue · /rules/ncci/ptp
The individual rule reads: the DMEPOS fee cell, the MUE unit cap, the PTP pair edit, each as of a date.
GET /archive/docs/{doc_id}/as-of · date
Which version of a policy document was in force on a date, with its sha256. The resolver behind every warrant.
public
GET /archive/docs/{doc_id}/versions
The full version history of a document: effective windows, hashes, and observation times.
public
GET /sources · /sources/{source_id}
The provenance catalog: every dataset Verzi ingests, with license, cadence, and accuracy classification.
key · free tier

Same wall on every surface. The warrant is the paid product on the API, the SDK, and the MCP alike: one entitlement, read by all three. Current-state and catalog reads stay free.

Status

v0.1, early access. Here is what that means.

The honesty rule applies to our own release notes too.

Today · v0.1

Built and in use

The generated client exists and tracks the live contract.

  • Generated types for all 264 /v1 paths · openapi-typescript
  • The authed client: X-API-Key plus an as_of default · openapi-fetch
  • CI drift guard: stale types fail the build

Early access: request a key and we will set you up with the SDK directly, on a claim type you pick. The package publishes to npm when the warrant responses are typed end to end.

Type the warranted record into your build.

Request a key, get the SDK, and make your first warrant call on your own claims.

Request access Read the docs

Rules data, not PHI. Nothing Verzi serves contains patient information.