Result objects

Everything on this page lives under eligibility_result.data_dump.data. The results page covers the envelope around it and which outcomes produce which of these objects.

data

Most objects below are absent rather than null when the check did not get far enough to produce them. Guard on presence, not on emptiness.

patient_info

Who the policy covers, as printed on the portal.

policy_holder_name is an empty string, not null, when the portal showed no name. patient_id_info is a payer-specific bag for identifiers that do not fit the fields above; its keys vary by payer, so read it defensively.

policy_network

The policy, the networks on it, and what the plan matched to.

all_networks

Each entry pairs the network name exactly as the portal wrote it with the normalised network it was matched to:

A null network on an entry means the raw name did not match anything we know. That is not an error, and in practice it is rare. The field that is routinely null is matched_plan_name, on roughly three eligible results in four. Neither is a degraded result: fall back to network_value and plan_code. See networks and plans.

Gatekeeper

is_gatekeeper and is_general_physician_referral_required_for_specialist_referral describe the same rule twice, one as a tri-state string and one as a boolean. When the rule applies, a matching entry usually appears in warning_messages as well.

The tri-state carries more information when the two agree: "Not Mentioned" is meaningfully different from "No", and the boolean flattens them together. They do not always agree.

copay_analysis

Cost sharing, benefit by benefit: what the patient pays, where, and under what conditions.

new_version_of_copay_analysis

A newer shape for the same information, emitted alongside the old one during the rollout. Both are present on results that have it.

copay_details_to_fill

The same cost sharing as copay_analysis, already resolved into the numbers a front desk types in. One entry per billing category: Outpatient, Maternity, Specialization and Inpatient, always in that order and always all four. Some accounts also receive a Dental category, so match on name rather than indexing by position.

Each category carries:

Reach for copay_analysis instead when you want the underlying policy terms, conditions and limits rather than a number to bill.

Some categories are the outpatient rate standing in

Payers rarely publish a separate specialist, maternity or dental cost-share table, so those categories come back all zeros. Specialization is then filled from the Outpatient block, and so are Maternity and Dental when you raise the check with visit_type: "MATERNITY" or "DENTAL", because the outpatient rate is what the visit is actually billed at.

Every service filled that way is flagged _is_outpatient_fallback: true.

Two encodings that catch people out

• Every money value is a string. "20.0", "0", not 20. Parse before you compare, and do not rely on truthiness.
• copay: "0" is not always zero. When it comes with should_set_copay: false the payer said "Not specified", so the 0 is a placeholder for "we do not know". This is the same distinction as is_eligible being null rather than false; collapsing it bills a patient at zero copay on a plan that never quoted one.

values_to_fill exists only inside a category. There is no top-level data.values_to_fill, despite the name appearing in some older integration notes.

The whole array is emptied when a member is found but not eligible, so an empty copay_details_to_fill is not a zero copay.

referral_documents

Documents pulled from the portal during the check: the member eligibility document, claim forms, tables of benefits. Each entry is an object, not a bare URL: s3_url is the link, tag is the label to show a human, and id is a slug for the same kind of document across checks.

id is absent at some payers, so display tag and prefer it if you need something to group on.

The same array appears in interim_results before the parse finishes, so you can show documents early while you are still polling.

Link expiry

Every s3_url in referral_documents, and screenshot_key, is a presigned Azure blob URL with a limited lifetime. GET /eligibility-result re-signs them every time it serves a result, so:

• Do cache the result and re-request it when you need the files.
• Do not cache the URLs, put them in an email, or hand them to a client that will open them hours later.

A link that has expired is not a lost document. Read the result again and you get a fresh one.

Keys this site does not document

Responses carry a number of keys that exist for our workers, our caches and one customer's hospital integration. They are not part of the contract, they change without notice, and some of them leak internal identifiers, so they are removed from every sample published here, and they are not documented.

If you find yourself needing one of these, tell us what you are trying to do. The answer is usually a field we should add properly rather than one you should depend on.