Quickstart

Goal: get an access token, confirm your authentication is wired up, then run a real eligibility check against the test environment. No PHI is exchanged. The test environment serves deterministic, PHI-free responses from ClaimRev's Mock Library, matched on the subscriber id you send.

This walkthrough uses the test/staging environment. Switch to the production hosts and credentials when you're ready.

Prerequisites

A ClaimRev test account (set up during enrollment) with the Mock Library enabled. ClaimRev turns this on during onboarding so your test eligibility calls return canned scenarios instead of hitting a live payer.
A Client ID and Client Secret from Practice Admin › API Integrations › Client Applications in the test portal. See Client Applications. If your application has a key file instead of a secret (ClaimRev's new ZITADEL sign-in), see Signing in with a key file below.
curl (or your HTTP client of choice). Postman works equally well; create a collection with an OAuth 2.0 auth profile and paste the token URL, scope, client id, and secret from below.

Step 1: Get an access token

curl -X POST \
  "https://stagingclaimrevcom.b2clogin.com/stagingclaimrevcom.onmicrosoft.com/B2C_1_sign-in-only/oauth2/v2.0/token" \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "scope=https://stagingclaimrevcom.onmicrosoft.com/portal/api/.default"

Response:

{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOi...",
  "token_type": "Bearer",
  "expires_in": 3600
}

Save the access_token — it's valid for one hour. Set it as a shell variable so the next steps stay readable:

export TOKEN="eyJ0eXAiOiJKV1QiLCJhbGciOi..."

Signing in with a key file

A key file can't be turned into a token with a plain curl call: your code signs a short-lived assertion with the key first. Follow Authentication → Signing in with a key file (it has C# and Python examples) using the staging values, then continue below with one change: add this header to every call.

-H "x-auth-tenant: zitadel"

Without it the API rejects a valid key-file token with 401.

Step 2: Confirm your auth works

The fastest sanity check is fetching your default account. It's a single GET with no body and tells you the token is valid and bound to a real account.

curl -X GET "https://testapi.claimrev.com/api/UserProfile/v1/GetDefaultAccount" \
  -H "Authorization: Bearer $TOKEN"

The response is your 5-character account number:

"DEMO1"

If you get a 401, the token is missing/expired/wrong-environment. If you get a 403, the token is valid but the client isn't bound to an account or has no roles. Check the application under Client Applications, including Manage roles. See Authentication → Errors.

Step 3: Run a real eligibility check

Now make a substantive call. SharpRevenue's RunSharpRevenue is the canonical eligibility entry point: JSON in, parsed 271 + raw EDI back, no patient pre-loading required.

In mock mode, the response is chosen by the subscriber id you send in payers[].subscriberNumber. Use MBCBSA to hit the seeded active-BCBS scenario:

curl -X POST "https://testapi.claimrev.com/api/SharpRevenue/v1/RunSharpRevenue" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "practiceName": "Quickstart Test",
    "requestingSoftware": "curl",
    "npi": "1234567890",
    "practiceState": "OK",
    "patientFirstName": "Pat",
    "patientLastName": "Sample",
    "patientGender": "F",
    "patientDob": "1990-01-15",
    "patientState": "OK",
    "productsToRun": [1],
    "payers": [
      {
        "isRevenueToolsPayerId": true,
        "payerNumber": "00015",
        "payerName": "BCBS of Indiana (Anthem)",
        "subscriberNumber": "MBCBSA"
      }
    ]
  }'

You should get back a response with active coverage details, the parsed 271 fields, and the raw 271 EDI embedded. The active-BCBS scenario keys on the subscriber id only, so the patient name and payer above are placeholders. Swap subscriberNumber for another seeded id to see different outcomes, e.g. 4EG1TE2MK75 (inactive) or MCCOB1 (active Medicare with COB). The full scenario catalog is in the SharpRevenue Testing Guide.

If you got a 200 with a 271 in the body, you're integrated.

Switching to production

When you're ready to go live:

Get a production Client ID + Secret from Client Applications on https://portal.claimrev.com. Production is a different account and credential pair from test.
Swap all four endpoint values:

	Test	Production
Token URL	`https://stagingclaimrevcom.b2clogin.com/stagingclaimrevcom.onmicrosoft.com/B2C_1_sign-in-only/oauth2/v2.0/token`	`https://portalclaimrev.b2clogin.com/portalclaimrev.onmicrosoft.com/B2C_1_sign-in-service/oauth2/v2.0/token`
Scope	`https://stagingclaimrevcom.onmicrosoft.com/portal/api/.default`	`https://portalclaimrev.onmicrosoft.com/portal/api/.default`
API server	`https://testapi.claimrev.com`	`https://api.claimrev.com`
Portal	`https://testportal.claimrev.com`	`https://portal.claimrev.com`

With a key file, use the ZITADEL token URL and audience from Authentication → Environments instead, and a production key file: a test key is rejected in production.

Replace the mock subscriber id with real patient + payer data. The Mock Library scenarios (the MBCBSA example above) exist only in the test environment; in production real payer responses come back.

Next steps

Concepts — the vocabulary of the API (accounts, claims, ERAs, eligibility)
Authentication — token lifetime, rotation, error handling
SharpRevenue Testing Guide — the full mock-data catalog and product list
API Reference — every endpoint

Prerequisites​

Step 1: Get an access token​

Signing in with a key file​

Step 2: Confirm your auth works​

Step 3: Run a real eligibility check​

Switching to production​

Next steps​