Retrieve HSA/FSA customer eligibility by provision request

Returns customer eligibility for a customer who does not hold a payment token yet, keyed on the provision request id you received from create_payment_token.

The token-keyed form and this one answer the same question — which items this customer can charge to their HSA/FSA card. Use this one for a customer's first order, where you have a provision request but no token; switch to the token form once the token arrives.

The two are keyed differently, and that is deliberate. A provision request names a customer and nothing else, so this form counts the letters that customer earned on your sales channel. The token form has a token to count letters through as well, and counts both.

The window this form exists for is the one before a token: the customer has answered the survey, no clinician has decided, so nothing has been minted to key the token form on, and you still need something to present your catalog with. pending is the ordinary answer here, where on the token form it is the rare one. In that state items carries what the survey predicts the letter will cover, intersected with your catalog, and lmn_expires_at is null because no letter exists yet. Those items are a prediction, not a decision — present them as provisional. items is empty only while the survey itself is unfinished.

Once a clinician decides, this key keeps working and starts answering exactly as the token-keyed form does: approved, expired, rejected, or never_requested, with a real coverage date where one exists (inclusive, UTC). That makes it a reliable poll if the payment_token.updated webhook is ever lost — and unlike the Retrieve Provision Token Request endpoint, whose payment_token is null for both outcomes, this one tells a pending letter apart from a rejected one.