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 uses deterministic mock responses keyed off subscriber names.

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).
• A Client ID and Client Secret retrieved from Client Connect in the test portal — see Authentication → Getting credentials.
• 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..."

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 — re-check Client Connect. 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.

The test environment returns deterministic mock results keyed off the subscriber's first name. Use a name starting with J to get an Active coverage response:

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": "Jordan",
    "patientLastName": "Test",
    "patientGender": "F",
    "patientDob": "1990-01-15",
    "patientState": "OK",
    "productsToRun": [1],
    "payers": [
      {
        "isRevenueToolsPayerId": true,
        "payerNumber": "00015",
        "payerName": "BCBS of Indiana (Anthem)",
        "subscriberNumber": "M45695321"
      }
    ]
  }'

You should get back a response with Active coverage details, the parsed 271 fields, and the raw 271 EDI embedded. The full mock-name catalog (I for Not Found, K + matching last name for specific subscriber ids, L for Inactive, etc.) 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:

1. Get a production Client ID + Secret from Client Connect on https://portal.claimrev.com (the prod portal — different account/credential pair from test).
2. 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

3. Replace mock subscriber names with real patient + payer data. Mock-name behaviors (the Jordan/Test pattern above) do not apply 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