Retrieve HSA/FSA customer eligibility by payment token

Returns the items this customer can charge to their HSA/FSA card, and when that stops being true.

This is customer eligibility — a property of the person rather than the product. It is catalog eligibility narrowed to one customer: an item appears here only when they hold a verified, unexpired Letter of Medical Necessity covering its eligibility category, or when that category is pre-approved and needs no letter at all.

eligibility_status and lmn_expires_at answer for the payment token you name, not for whoever holds it. They count the letters reachable through the token together with the letters the holder earned on your sales channel. A customer who answers our health survey under a second email address earns their letter on that address while the token stays where it was minted, and counting both is what keeps that letter visible here. The payment_token.updated webhook counts the same letters, so a token reads the same way on both surfaces. The provision-request form answers for a customer who holds no token yet, and is keyed on the customer.

eligibility_status is a statement of fact, not an instruction, and each value earns a different response from you — the per-value meanings are listed on the enum. In short: approved is the steady state; expired is your renewal trigger, while every item keeps charging to the backup card meanwhile; never_requested calls for a first-time qualification prompt rather than a renewal one; rejected means suppress the prompt rather than sending the customer round again, since we have already emailed them the outcome; and pending means wait.

pending is rare on this form, because a payment token is normally minted only once a letter has been decided. It appears when a customer who is not currently covered has a survey under review — a requalification in flight, most often.

An empty items list under approved is worth reporting to us rather than to your customer: it means a live qualification exists but nothing in your catalog falls under it any more, which a re-survey cannot fix.

Read it on whatever schedule suits you; the answer is stable through lmn_expires_at (inclusive, UTC).