Retrieve Provision Request Eligibility

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 — and differ only in how you name the customer. 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. This is the only form that returns `pending`, and the window it covers is the wait for a clinical decision: the customer has answered the survey, no clinician has decided, and you still need something to present your catalog with. 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. 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.