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 in this section is a real completed production check. The shapes,
key names, statuses and structure are exactly what the API returned. Every
identifier has been replaced with the placeholder for its field, so
784-0000-0000000-0 and MBR-0000000 stand where a real member's numbers were.
The figures are redrawn from the portal pages rather than screenshotted, for
the same reason.
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 |
|---|---|---|
| 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 |
| Not found, then found | The same patient answers differently on a second try | 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 |
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
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.
Payer-specific requirements
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.