Mantys Eligibility APIProduction cases
Nine situations that break a first integration, each with what the portal showed, the response it produced, and the branch your code needs.
The results and result objects pages describe the response one field at a time. This section does the opposite: it starts from a situation a clinic actually hits, shows what the payer put on the screen, and then shows the body that came back.
Every sample on the case pages below is a real completed production check. The shapes,
key names, statuses and structure are exactly what the API returned. What has
been replaced is the member: their name, identifiers, birth date and phone, and
nothing else. Most pages here show that as a blank placeholder, so
784-0000-0000000-0 and MBR-0000000 stand where a real member's numbers were.
A few show it as an invented but well-formed member instead, because a screen of
zeros is hard to read as a screen. Either way the same fake member stands
throughout, so an identifier that repeats across two samples repeated in the
real ones too.
These are the cases that produce a wrong answer, not an error
Almost nothing here fails loudly. A policy with two networks returns 200, a copay that varies by location returns 200, and a payer that has no credentials on file returns 200. What separates them is what a client does with the body, so each page ends with the branch the case requires.
The cases
| Case | What happens | The trap |
|---|---|---|
| Eligible response structure | The check returns eligible and complete: the baseline read | The ten fields a desk acts on sit four levels down, renamed |
| Networks and plans | One policy carries more than one network | Four fields name the network and they do not agree |
| Copay | Cost sharing differs per benefit and per location | A single headline copay number is almost always wrong |
| Search-all | Nineteen payers answer, in five different ways | Reading the first result, or treating a failure as "not covered" |
| Daman multi-card | The member holds two packages at one payer | This endpoint returns one of them, arbitrarily |
| Failures | The check does not produce a determination | The task still reports PROCESS_COMPLETE |
| Emirates ID not linked | One payer, one member, two identifiers, two answers | Only one of the two reasons is worth retrying |
| Visit types | Your encounter types do not map one to one | Three Mantys visit types share one clinical encounter |
| Documents and warnings | The response carries files and portal notices | The links expire, and the notices are objects |
Start with eight outcomes if you are still deciding what to branch on. It is the only page here not built around a single situation: it takes all eight things a finished check can report, splits them into the three that answer about the patient and the five that report on the run, and shows the captured body behind each one. The pages above then take one of those outcomes apart in the setting that produces it.
One page in this section carries no capture. Common search
scenarios works the other way round, from the request
rather than the response: the combinations of tpa_name, id_type and
extra_args that return 200 and still need care, each one openable in the
simulator.
How to read a case
Each page has the same three parts.
What the portal showed. A redrawn panel of the payer page the check read, with numbered callouts. This is the ground truth the response is derived from.
What came back. The relevant slice of the real response body, captured from the production task and scrubbed. Paths are given in full from the top of the response, so you can find the same value in your own.
What your code has to do. The branch, in one or two sentences, plus what happens if you skip it.
Where to go next
Eight outcomes
Every status a finished check can report, and the branch each one needs.
Results
The envelope and one section per outcome, if you have not read it yet.
Result objects
Field by field through patient_info, policy_network and the copay objects.
Common search scenarios
What to send: the combinations of tpa_name, id_type and extra_args that need care.
Try it
Build a request in the browser and step through the responses.