Build with the Clarity API.

Your first request.

1. Create a Clarity account and open API keys in your workspace.
2. Create a key with the estimates:write permission. Copy it once and store it in your backend’s secret environment as CLARITY_API_KEY.
3. Send the request below from your application server or terminal.

curl https://clarity-revenue.vercel.app/api/v1/revenue/estimate \
  -H "Authorization: Bearer $CLARITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "monthlySelfPayEncounters": 1000,
    "averageClaimValue": 450,
    "discoveryRate": 0.2
  }'

Calls require no Clarity session cookie. An API key is all your backend needs. You can also test the same endpoints in the API playground.

A key for every connection.

Pass your key in the Authorization: Bearer <key> header. Keys start with cl_test_, belong to your account, expire after 90 days, and can be revoked immediately. The full secret is returned once at creation; only a hash is stored.

Create separate keys for separate apps and select only required scopes. Rotate a key by creating its replacement, updating your backend, and revoking the old key.

Revenue opportunity estimates.

Models gross billable opportunity from aggregate volume and your assumptions. It performs no insurance discovery or payer verification.

{
  "data": {
    "currency": "USD",
    "potentialMonthlyBillableValue": 90000,
    "potentialAnnualBillableValue": 1080000,
    "additionalCoveredEncountersPerMonth": 200,
    "basis": "user_supplied_assumptions",
    "limitations": [
      "Gross billable value; not collected or guaranteed revenue.",
      "Excludes collection losses, fees, and costs.",
      "No payer verification or insurance discovery was performed."
    ]
  },
  "requestId": "your-request-uuid"
}

Formula: monthly encounters × average claim value × discovery rate. The monthly billable value is rounded to cents and multiplied by 12 for the annual figure.

Workflow evaluation.

Turn facts supplied by your application into review priorities. This is a deterministic rules engine, not an insurance eligibility service or a clinical recommendation.

{
  "encounterReference": "DEMO_2048",
  "claimValue": 450,
  "coverageKnown": true,
  "eligibilityVerified": false,
  "authorizationRequired": true,
  "authorizationStatus": "pending",
  "deductibleRemaining": 0,
  "daysUntilFilingDeadline": 12,
  "retroactiveCoverage": false
}

Rules your team can understand.

• Unknown coverage → review coverage.
• Known coverage without reported verification → verify eligibility through your provider.
• Required authorization that is not approved → review authorization.
• Remaining deductible → review deductible responsibility.
• Reported retroactive coverage → review dates and previous submissions.
• Filing window of 14 days or fewer → urgent filing review.

Responses include method: "rules_based", payerVerified: false, and action priorities. A no_rule_flags result does not establish eligibility or guarantee a clean claim.

AI intelligence, grounded in facts.

Calculate the evidence first, then ask AI to explain the opportunity, propose next actions, assign owners, identify questions, and suggest a measurable pilot. Reviews are saved to your workspace.

{
  "kind": "opportunity",
  "organizationType": "ems",
  "data": {
    "monthlySelfPayEncounters": 1000,
    "averageClaimValue": 450,
    "discoveryRate": 0.2
  }
}

Use organizationType: ems, hospital, specialty, or rcm. Use kind: opportunity, workflow, or readiness. Opportunity data uses the estimate schema. Workflow data uses the workflow schema and requires a reference starting DEMO_ or TEST_.

Readiness review data

{
  "kind": "readiness",
  "organizationType": "rcm",
  "data": {
    "monthlyEncounters": 1200,
    "selfPayPercentage": 25,
    "denialPercentage": 12,
    "manualMinutesPerEncounter": 10,
    "ehrConnectionReady": false
  }
}

Readiness ranges: monthlyEncounters is an integer from 0 to 1,000,000; percentages are numbers from 0 to 100; manual minutes are a number from 0 to 240; ehrConnectionReady is a boolean. Workload hours are calculated as volume × minutes / 60, not predicted savings.

Responses include headline, summary, nextActions with owners and cited evidence, questionsToResolve, suggestedPilot, calculated evidence, report id, and humanReviewRequired: true.

A prioritized workflow queue.

Send { "encounters": [...] } with 1–25 objects matching the workflow schema. The response contains a deterministic queue sorted urgent, high, then normal. It includes total encounter count and reviewRequired count. No payer verification is performed.

Understand your usage.

Returns this calendar month’s request count, allowance, active key count, average logged latency, error count, and the last 20 authenticated requests. Request metadata includes endpoint, status, timing, and request ID; request bodies and response bodies are not stored in activity logs.

Successful key authentication consumes a request, including calls that return a validation error. Usage reads also count. Missing keys, invalid keys, wrong scopes, and rate-limit rejections do not consume the monthly quota.

Connect your own SaaS.

For a REST-capable platform, configure a server-side HTTP action with the following settings. No platform-specific SDK is required.

JavaScript / Node.js

const response = await fetch(
  "https://clarity-revenue.vercel.app/api/v1/revenue/estimate",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.CLARITY_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      monthlySelfPayEncounters: 1000,
      averageClaimValue: 450,
      discoveryRate: 0.2
    })
  }
);

const result = await response.json();
if (!response.ok) {
  throw new Error(result.error.message);
}
console.log(result.data.potentialAnnualBillableValue);

Python

import os
import requests

response = requests.post(
    "https://clarity-revenue.vercel.app/api/v1/revenue/estimate",
    headers={
        "Authorization": f"Bearer {os.environ['CLARITY_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={
        "monthlySelfPayEncounters": 1000,
        "averageClaimValue": 450,
        "discoveryRate": 0.2,
    },
    timeout=30,
)
response.raise_for_status()
result = response.json()["data"]

These examples apply to platforms that support server-side REST calls. Specific platforms may require their own connector settings; compatibility with a named third-party platform has not been independently verified.

Clear limits. Clear errors.

Developer beta includes 10,000 requests per account per UTC calendar month, 60 requests per minute per key, and 10 active keys. Request bodies are limited to 16 KB.

Responses include X-Request-Id. Authenticated endpoint responses also include X-RateLimit-Limit, X-RateLimit-Remaining, and X-Monthly-Remaining headers.

{
  "error": {
    "code": "insufficient_scope",
    "message": "This key does not have the scope required by this endpoint."
  },
  "requestId": "your-request-uuid"
}

Coverage history & ambulance review

Caller-submitted synthetic snapshots persist in your workspace. Changes create in-app alerts; identical submissions do not create duplicates. No live payer verification, automatic monitoring, email, or SMS delivery.

POST /api/v1/coverage/snapshots requires coverage:write. GET /api/v1/coverage requires coverage:read and returns test records, latest 100 alerts, and latest 100 snapshots. POST /api/v1/coverage/alerts/{id}/acknowledge requires coverage:write. See the OpenAPI schema for required fields and enums.

Maximum 100 distinct test records per workspace. Use expectedRevision for concurrent updates, observedAt for delayed observations, and a stable Idempotency-Key for safe retries (seven-day retention). Conflicts return 409. Use TEST_ or DEMO_ references only. Transport decisions are not assessed; payment is not guaranteed.

Primary, secondary and previous insurance

Coverage snapshots support an optional plans array (maximum 10 policies) plus serviceDate. Each policy records a unique test ID, demo payer, test member reference, reported payer order, reported status, effective/end dates, ambulance benefit, network and authorization status. Dates may be null when unknown. Real patient identifiers and live payer names are not accepted.

The review.insurance response separates previous, current-date-window, upcoming and undated policies. A previous policy may fall within the service date; the date comparison does not establish payer verification. Overlapping primary policies, missing primary coverage for a secondary plan, and missing dates create review issues. Reported payer order is never presented as verified coordination of benefits. Secondary coverage does not guarantee payment.

Policies are canonicalized by ID, so changing array order does not create a false change alert. Omitting plans preserves previously saved policies during legacy summary updates. Sending plans replaces the policy list, including any previous policies you want displayed. Prior snapshot values remain accessible within the configured history retention. See the OpenAPI schema for all required fields.

Sessions, exports and complete alert browsing

Security & launch lists active sessions and lets you sign out other devices. Session tokens are excluded from this view; session revocation does not revoke API keys.

Workspace JSON exports include up to 1,000 retained records per section and a complete flag. Each section declares hasMore if additional records exist. Passwords, API secrets, MFA secrets and session tokens are excluded.

GET /api/v1/coverage/alerts and GET /api/v1/coverage/history require coverage:read. Use limit=1–100 (default 50) and cursor=nextCursor for later pages. Alerts also support status=all, unread or reviewed. Invalid cursors return 422. The console counts all unread alerts and supports loading older records.

Security and launch status

Authenticator-based two-factor sign-in and recovery codes are available under Security & launch. Coverage writes and key actions have a workspace audit trail. API metadata, synthetic coverage history and saved AI reports are retained for 90 days; audit events for one year. A secret-protected daily job performs cleanup.

AI has a cap of 100 reviews across the project per UTC month, in addition to 20 per workspace per day. Workflow references require TEST_ or DEMO_ prefixes. Email verification, recovery email, live payer monitoring, external uptime alerts and a backup restore drill remain launch requirements. View your launch status.

What is connected today.

The SaaS has persistent accounts, scoped API keys, rate limits, usage logging, revenue estimates, workflow rules, batch queues, and saved AI reviews.

No live payer, EHR, claims-clearinghouse, or patient systems are connected. Live healthcare data features need licensed provider agreements, production security and compliance work, and separate integration testing. This developer beta must not receive patient information.

Billing, team invitations, email verification, and password recovery emails are not configured. Account passwords can be changed from an authenticated workspace. This site does not claim healthcare compliance certification.