Mantys Eligibility APIPayer-specific requirements
Combinations that return 200 and still need care: search-all, member IDs, the maternity extra, and Daman.
Three fields decide what a check actually does: who you ask (tpa_name), how
you name the patient (id_type), and what the payer needs on top
(extra_args). They interact, and almost none of it is validated.
Every case on this page returns 200
create-task checks the Emirates ID prefix and nothing else. A combination that cannot work is
still accepted, still queued, and still run: what tells the cases apart is the answer, and
sometimes it is a confidently wrong one. That is why they are worth reading before you meet one in
production.
Each card below loads into the Try it simulator from the same object it prints, so you can send the request in your browser and read the response it produces without touching the API.
The worked cases
Named payer, Emirates ID
Send thisThe baseline every other example is a delta from. The 784 prefix is checked before the task is created, so a mistyped ID costs you nothing.
{
"tpa_name": "TPA004",
"id_type": "EMIRATESID",
"id_value": "784-0000-0000000-0",
"visit_type": "OUTPATIENT"
}Search-all, Emirates ID
Send thisWhen you do not know the payer. The create response carries is_search_all and search_all_status, and the result carries aggregated_results instead of eligibility_result. Daman is never in the fan-out.
{
"tpa_name": "BOTH",
"id_type": "EMIRATESID",
"id_value": "784-0000-0000000-0",
"visit_type": "OUTPATIENT"
}Named payer, member ID or card number
Send thisThe retry when the Emirates ID is not linked at the payer yet, which is common for a newly issued card or a dependant added mid-policy. Only the payers whose scraper reads id_type can do this; the TPA matrix lists them.
{
"tpa_name": "TPA004",
"id_type": "CARDNUMBER",
"id_value": "MBR-0000000",
"visit_type": "OUTPATIENT"
}Search-all, member ID or card number
Worth knowingAccepted, and the sweep runs. Reach for it when you do not know the payer and the patient has their card but not their Emirates ID. Send the Emirates ID instead when you have one: it is the only identifier every payer accepts, so a sweep has the most to match on. Daman is never included in a search-all whichever identifier you send.
{
"tpa_name": "BOTH",
"id_type": "CARDNUMBER",
"id_value": "MBR-0000000",
"visit_type": "OUTPATIENT"
}Daman, where visit_type is not inpatient or outpatient
Needs a payer-specific valueEvery other payer takes some variation of OUTPATIENT and INPATIENT. Daman takes a service taxonomy instead: consultation reasons, ultrasound trimesters, dental fee models, and two flows that are not visits at all (VALIDITY_CHECK and BABY_FLOW). Nothing is validated at create time, so OUTPATIENT is accepted here and then fails at the portal. Pick the value from the Daman row of the TPA matrix.
{
"tpa_name": "TPA023",
"id_type": "EMIRATESID",
"id_value": "784-0000-0000000-0",
"visit_type": "CONSULTATION_ELECTIVE"
}Maternity at NAS or Neuron
Needs a payer-specific valueBoth payers ask whether the maternity treatment is inpatient, and nothing makes you answer. Omitting maternity_treatment is not an error: the portal answers as though you had said no, and you get outpatient maternity cover back without being told.
{
"tpa_name": "TPA004",
"id_type": "EMIRATESID",
"id_value": "784-0000-0000000-0",
"visit_type": "MATERNITY",
"extra_args": {
"maternity_treatment": true,
"is_member_present_at_the_facility": true
}
}extra_args, by payer
Two payers ask for something beyond the three fields. Everyone else reads no extras at all, and sending them anyway is harmless.
| Payer | Asks for | When | If you leave it out |
|---|---|---|---|
TPA001Neuron LLC | maternity_treatmentIs inpatient treatment? | visit_type is MATERNITY | the portal answers as though you had said no |
is_member_present_at_the_facilityMember present at the facility? | Every check | the portal is told the member is present | |
TPA004NAS Administration Services | maternity_treatmentIs inpatient treatment? | visit_type is MATERNITY | the portal answers as though you had said no |
is_member_present_at_the_facilityMember present at the facility? | Every check | the portal is told the member is present |
Those 2 are the whole list: every other payer reads no extras at all, and sending one anyway is ignored rather than rejected. The shape of each is on the create-task page, and getting a shape wrong fails silently.
Leaving the answer out is not an error
Neither extra is required and neither is validated, so a maternity check with no
maternity_treatment is accepted and runs. The payer's "Is IP Maternity" question is then
answered No, and you get outpatient maternity cover with no error and no warning for a request
that asked about inpatient. Send the key whenever visit_type is MATERNITY. The older title /
value pair is still accepted; see extra_args.
Daman's visit types
Daman is the exception twice over. It is never part of a search-all, so it has
to be asked for by code. And its visit_type is a service taxonomy rather than
the usual inpatient and outpatient split, so the value every other payer takes
is not one Daman accepts.
Nothing rejects a wrong value at create time. The task is created, the check runs, and the failure comes back from the payer minutes later.
INS026Daman (National Health Insurance Company)22 accepted valuesCONSULTATION_ELECTIVEConsultation - ElectiveCONSULTATION_EMERGENCYConsultation - EmergencyCONSULTATION_ONCOLOGYConsultation - OncologyCONSULTATION_REFERRALConsultation - ReferralCONSULTATION_SCREENINGConsultation - ScreeningCONSULTATION_VACCINATIONConsultation - VaccinationINPATIENTIn PatientTELEHEALTHTele-Consultation / TelemedicineFREE_FOLLOWUPFree Follow-up (not reimbursable)DIAGNOSTICDiagnostic TestingPHYSIOTHERAPYPhysiotherapyDENTAL_SERVICESDental ServicesPHARMACYPharmacyHOMECAREHomecareREHABILITATIONRehabilitationDAYCAREDaycareULTRASOUND_FIRST_TRIMESTERUltrasound - First TrimesterULTRASOUND_SECOND_TRIMESTERUltrasound - Second TrimesterULTRASOUND_THIRD_TRIMESTERUltrasound - Third TrimesterOTHER_OPOther OP ServicesVALIDITY_CHECKValidity CheckBABY_FLOWBaby Flow
TPA023Daman Thiqa25 accepted valuesCONSULTATION_ELECTIVEConsultation - ElectiveCONSULTATION_EMERGENCYConsultation - EmergencyCONSULTATION_ONCOLOGYConsultation - OncologyCONSULTATION_REFERRALConsultation - ReferralCONSULTATION_SCREENINGConsultation - ScreeningCONSULTATION_VACCINATIONConsultation - VaccinationINPATIENTIn PatientTELEHEALTHTele-Consultation / TelemedicineFREE_FOLLOWUPFree Follow-up (not reimbursable)DIAGNOSTICDiagnostic TestingPHYSIOTHERAPYPhysiotherapyDENTAL_SERVICESDental ServicesPHARMACYPharmacyHOMECAREHomecareREHABILITATIONRehabilitationDAYCAREDaycareULTRASOUND_FIRST_TRIMESTERUltrasound - First TrimesterULTRASOUND_SECOND_TRIMESTERUltrasound - Second TrimesterULTRASOUND_THIRD_TRIMESTERUltrasound - Third TrimesterOTHER_OPOther OP ServicesDENTAL_SERVICES_CAPITATION_PROGRAMDental Services - Capitation ProgramDENTAL_SERVICES_ROUTINE_FFSDental Services - Routine FFSDENTAL_SERVICES_ADVANCED_FFSDental Services - Advanced FFSVALIDITY_CHECKValidity CheckBABY_FLOWBaby Flow
INS078Daman MSC20 accepted valuesCONSULTATION_ELECTIVEConsultation - ElectiveCONSULTATION_EMERGENCYConsultation - EmergencyCONSULTATION_ONCOLOGYConsultation - OncologyCONSULTATION_REFERRALConsultation - ReferralCONSULTATION_SCREENINGConsultation - ScreeningCONSULTATION_VACCINATIONConsultation - VaccinationINPATIENTIn PatientTELEHEALTHTele-Consultation / TelemedicineFREE_FOLLOWUPFree Follow-up (not reimbursable)DIAGNOSTICDiagnostic TestingPHYSIOTHERAPYPhysiotherapyDENTAL_SERVICESDental ServicesPHARMACYPharmacyHOMECAREHomecareREHABILITATIONRehabilitationDAYCAREDaycareULTRASOUND_FIRST_TRIMESTERUltrasound - First TrimesterULTRASOUND_SECOND_TRIMESTERUltrasound - Second TrimesterULTRASOUND_THIRD_TRIMESTERUltrasound - Third TrimesterOTHER_OPOther OP Services
D004Daman Basic22 accepted valuesCONSULTATION_ELECTIVEConsultation - ElectiveCONSULTATION_EMERGENCYConsultation - EmergencyCONSULTATION_ONCOLOGYConsultation - OncologyCONSULTATION_REFERRALConsultation - ReferralCONSULTATION_SCREENINGConsultation - ScreeningCONSULTATION_VACCINATIONConsultation - VaccinationINPATIENTIn PatientTELEHEALTHTele-Consultation / TelemedicineFREE_FOLLOWUPFree Follow-up (not reimbursable)DIAGNOSTICDiagnostic TestingPHYSIOTHERAPYPhysiotherapyDENTAL_SERVICESDental ServicesPHARMACYPharmacyHOMECAREHomecareREHABILITATIONRehabilitationDAYCAREDaycareULTRASOUND_FIRST_TRIMESTERUltrasound - First TrimesterULTRASOUND_SECOND_TRIMESTERUltrasound - Second TrimesterULTRASOUND_THIRD_TRIMESTERUltrasound - Third TrimesterOTHER_OPOther OP ServicesVALIDITY_CHECKValidity CheckBABY_FLOWBaby Flow
D002Daman ABMnot enumeratedVALIDITY_CHECK and BABY_FLOW are not visits at all. They are separate portal
flows reached through the same field: a validity check confirms the card is live
without pricing an encounter, and the baby flow covers a newborn not yet on the
policy in their own right.
What is not a special case
Four things look like special handling and are not:
- A
member_not_foundresult. Not an error and not a dead end on its own. It usually means the Emirates ID is not linked at the payer yet, which the member ID case above is the retry for. - A member ID in a search-all. Accepted, and the sweep runs. Send the Emirates ID when you have one, but a card number is not a dead end.
- Sending
doctorIdeverywhere. Only payers that generate a claim form read it, FMC (TPA010) above all. The rest ignore it. name,dobandphone. Optional on every payer. A few portals search better with them, none require them.
Where to go next
Try it
Build any of these requests in the browser and step through the responses.
Create a task
Every request field, the two server-side defaults, and the reference note behind each case.
Payer matrix
Which identifiers and visit types each payer accepts, and which are in search-all.
Outcomes
What each of these requests can come back as, and how to tell them apart.