SharpRevenue Tools — API Testing Guide

This guide walks through running real-time patient lookups against the SharpRevenue Tools API. It covers the products you can run, the canonical endpoints, and the deterministic mock data the test environment returns so you can build automated integration tests without needing real PHI.

Products

SharpRevenue exposes four product types, addressed by id in the productsToRun array on every request.

Product ID	Product	Use it when…
1	Eligibility	You have full insurance information for the patient and want to verify active coverage.
2	Demographics	You want top-level credit-report data (address, gender, SSN). Used in Insurance Discovery flows.
3	Coverage Discovery	You don't know what insurance the patient has — this fishes for it from supplied identifiers.
5	MBI Finder	You have a patient's old Medicare member id and need their current MBI.

Note. A future product 4 (Prior Authorization) is in design but not currently functional. Don't include 4 in productsToRun today.

API surface

The full surface is documented in the API Reference. The handful of endpoints used most often during integration testing:

Action	Endpoint
Run a SharpRevenue request	POST /api/SharpRevenue/v1/RunSharpRevenue
Re-check the status of a transaction	POST /api/SharpRevenue/v1/CheckTransactionStatus
Re-fetch a stored result by id	GET /api/SharpRevenue/v1/GetEligibility?sharpRevenueRtEligibilityObjectId={id}

There are many additional endpoints for searching patients, managing clinics, and exporting CSV results. If your integration is an EMR-style system that already manages patients, most of the patient-management endpoints won't be relevant — focus on the request/result endpoints above. Reach out to ClaimRev support with questions about which endpoint fits your integration shape.

Identifying results

Most SharpRevenue API responses include a claimRevResultId property — this is the primary key for the result inside ClaimRev. Use it for status checks, re-fetching, and correlating across endpoints.

The response also includes mappedData.transactionId (e.g., VarnerHeathDEMO120250108095731294), which is the unique transaction number used by CheckTransactionStatus.

Run SharpRevenue

POST /api/SharpRevenue/v1/RunSharpRevenue
Content-Type: application/json
Authorization: Bearer <token>

{
    "practiceName": "My DEMO Account",
    "requestingSoftware": "Post Man",
    "npi": "1234567890",
    "practiceState": "OK",
    "subscriberId": "string",
    "patientFirstName": "Heath",
    "patientLastName": "Varner",
    "patientGender": "M",
    "patientSsn": "778956541",
    "patientState": "OK",
    "patientDob": "2023-11-03",
    "productsToRun": [1],
    "payers": [
        {
            "isRevenueToolsPayerId": true,
            "payerNumber": "00015",
            "payerName": "BCBS of Indiana (Anthem)",
            "subscriberNumber": "M45695321"
        }
    ]
}

Most of the request body is housekeeping:

Property	Notes
accountNumber	Automatically set if left blank.
requestingSoftware	Free-form — name your integration.
clientId	Legacy; can be left blank.
uniqueTransactionNumber	Unique within your system. The server generates one if you leave it blank.
productsToRun	Array of product ids (see table above).
isRevenueToolsPayerId	true if you're using SharpRevenue's internal payer ids. false if you're sending the same payer id you'd put on a claim — ClaimRev will look up the mapping for you. EMRs sending claims to ClaimRev typically have claim payer ids configured per patient and should use false.

The 271 result is returned synchronously in the response body. The response also embeds the raw 271 EDI alongside the parsed structured data, so you don't need a separate request to get the EDI bytes.

Re-check status

POST /api/SharpRevenue/v1/CheckTransactionStatus
Content-Type: application/json
Authorization: Bearer <token>

{
    "accountNumber": "string",
    "uniqueTransactionNumber": "string"
}

uniqueTransactionNumber is the value from mappedData.transactionId on the original RunSharpRevenue response. The response shape is the same as RunSharpRevenue.

Re-fetch by result id

If you saved the claimRevResultId from the original request, you can re-fetch the same result without making a new payer call:

GET /api/SharpRevenue/v1/GetEligibility?sharpRevenueRtEligibilityObjectId={claimRevResultId}
Authorization: Bearer <token>

This is a GET — no request body. The response shape matches RunSharpRevenue.

Mock data — Demographics & Self-Pay (product 2)

When testing against the demographics part of the service, the response largely mirrors what you sent. Behavior varies by the patient's last name:

Last name starts with	Mock behavior
B	SSN is replaced with an arbitrary test value.
C	DOB is replaced with an arbitrary value, plus arbitrary red flags and warnings.
D	State is returned as KY.
E	An error is returned.
F	Name, address, SSN, and DOB are all returned as arbitrary values, yielding a low-confidence result.
Anything else	Echoes the request values unchanged.

Arbitrary landline and cell phone numbers are added to all non-error demographic responses.

Self-pay (credit) sub-behavior

The credit/self-pay portion is keyed off the first name:

First name	Credit behavior
Starts with A	Acceptable credit + employment info returned.¹
Starts with B	Poor credit + a past-due trade account.
Starts with C	Various credit info: employment, two trade accounts (one installment, one revolving), a collection account, and a public record.
Starts with anything else	The second letter of the first name is used as above if it's an A, B, or C. So Daniel → acceptable credit + employment, Doris → no credit record. This lets you exercise the credit mock service without conflicting with the eligibility mock service.
Otherwise	No credit information returned.

¹ Employment info from real vendors is sparse; the mock service mirrors that — not all fields will be populated.

Mock data — Eligibility & Insurance Discovery (products 1 and 3)

Eligibility mock behavior is driven by the subscriber's first name.

Test payer. Use payer number 00015 with payer name BCBS of Indiana (Anthem) and isRevenueToolsPayerId: true. If you want to test the claim-payer-id mapping path, use 00630 with isRevenueToolsPayerId: false.

First name pattern	Mock behavior
Starts with H	Active coverage if subscriberId is present, otherwise an AAA 72 validation (missing subscriber id).
Starts with I	Not Found with an AAA 42 validation (service temporarily unable to respond). To force a different AAA code, append a hyphen and the code — e.g., I-41 returns AAA 41.
Starts with J	Active coverage with subscriber id 908080808RW.
Starts with K + last name = payer name	Active coverage with subscriber id 99999999.
Starts with K + last name ≠ payer name	Not Found.
Starts with L + last name = payer name	Inactive coverage.
Starts with L + last name ≠ payer name	Not Found.
Starts with M	Active coverage with a full payer address.
Starts with N + member id not ending in T	Returns a corrected Medicare member id (substitutes a T for the last letter).
Starts with N + member id ending in T	Active Medicare coverage.
Starts with O	Unspecified coverage.
Starts with P	Active coverage, but with arbitrary first/last name and DOB — yields a low-confidence record.
Starts with Q	Active commercial coverage with deductible info.
Anything else	Not Found.

These deterministic behaviors let you build a test suite that exercises every meaningful eligibility outcome without contacting a real payer.

Moving to production

The mock data above is for the test environment only. Once your integration is working against tests, switch to production credentials and run real patient data — the mock-name behaviors don't apply in production. Reach out to ClaimRev support to be moved over.