Test IDs

A test ID is a member ID that starts with 990-. Send it to create-task instead of a real Emirates ID or card number and the task runs without contacting any payer. You poll it the same way as a real task. For 10 seconds it reports an in-flight status, then it returns a finished response copied from one of the production cases.

Use test IDs to build and test your client: the polling loop, the terminal statuses, and every branch the case pages describe. The number after 990- picks the response, so you can make each outcome happen whenever you need it.

This page shows the v3 calls. On API v4 the same IDs work on POST /v4/eligibility-checks, sent inside identifiers, with the same timing; that section lists how a v4 test check differs.

Sample requests

Set the same variables as in the Quickstart:

export MANTYS_API_KEY=...      # without the "Bearer " prefix
export MANTYS_CLINIC_ID=...
export MANTYS_CLIENT_ID=...
export BASE=https://hrcm-api.themantys.com/v2/api-integration-v3

curl -sS -X POST "$BASE/create-task" \
  -H "x-api-key: Bearer $MANTYS_API_KEY" \
  -H "X-Clinic-ID: $MANTYS_CLINIC_ID" \
  -H "X-Client-ID: $MANTYS_CLIENT_ID" \
  -H 'Content-Type: application/json' \
  -d '{
        "tpa_name": "TPA002",
        "id_type": "EMIRATESID",
        "id_value": "990-01",
        "visit_type": "OUTPATIENT"
      }'

Each one responds like a real create-task:

{
  "success": true,
  "message": "Task created successfully",
  "data": {
    "task_id": "99000000-0001-46aa-aedc-7511f88336aa",
    "status": "pending",
    "organization_api_task_db": {
      "task_id_in_db": "99000000-0001-46aa-aedc-7511f88336aa",
      "task_id_in_celery": "99000000-0001-46aa-aedc-7511f88336aa",
      "status": "IN_QUEUE"
    }
  }
}

Then poll with the returned task_id:

curl -sS "$BASE/eligibility-result/$TASK_ID" \
  -H "x-api-key: Bearer $MANTYS_API_KEY" \
  -H "X-Clinic-ID: $MANTYS_CLINIC_ID" \
  -H "X-Client-ID: $MANTYS_CLIENT_ID"

What a test task does

A search-all test task reports SEARCH_ALL_PROCESSING in both status and search_all_status for the first 10 seconds, with an empty aggregated_results. After that both fields read SEARCH_ALL_COMPLETE and the full list appears at once.

GET /task-status/{task_id} works too, and reports the same states with its usual simplified statuses.

The finished body is the captured response shown on the case page, with task_id, clinic_id and the timestamps changed to match your task. You can poll it again at any time and get the same body. A few things differ from a real check:

• request_dump is the captured request, not yours. It holds the placeholder member from the sample. Do not use it to match a response to the request you sent; use task_id. (On v4 the check's request echoes your own request instead; see API v4.)
• The document links do not load. screenshot_key and every referral_documents[].s3_url point at storage.example.com, a placeholder host.
• tpa_name, id_type and visit_type do not change the response. The number after 990- alone picks it. The case's own payer is in eligibility_result.tpa_name. Still send the fields you would send for a real check: on v3 tpa_name must not be empty, and sending search-all IDs with "tpa_name": "BOTH" keeps your client on its search-all path.
• The 784 prefix check does not apply. 990- IDs are accepted for every id_type.
• Nothing is sent to a payer. A test task causes no portal session and no lookup, and does not count against the payer's rate limits.
• Poll it exactly as you would a real task, with the same credentials and the same base URL you created it with.

Every test ID

Only the digits after 990 count, so 990-21 and 990-0000-0000000-21 both select case 21. A number that is not in this table returns a 400 listing the valid ones. Cases 990-90 to 990-99 are answered on v4 only; v3 returns that 400 for them.

The Shape column matters: some cases on single-payer pages were captured from a search-all and come back in the search-all shape, with aggregated_results in place of eligibility_result.

"Result" is eligibility_result.status for a single-payer response, and a count of aggregated_results[].status for a search-all. Every single-payer case finishes with a task status of PROCESS_COMPLETE, including the failures. For 990-90 to 990-99 it is each v4 row's status and each ahd_benefit_plans[].reason; those checks finish as COMPLETE.