IDX Screener API

REST access to the IDX screening models, published for client applications. Base URL for every endpoint: https://dev.multiscreener.qomu.ai/api.

Start here

Interactive mockup + API map — the FAIR screens with every component annotated: click any element to see which endpoint drives it, what to send, what comes back, and which field lands on which pixel. It is the fastest way to understand the integration.

Written guides

• FAIR Integration Guide
  Endpoint order, payloads and field mappings for the FAIR mobile flow.
• API Reference
  Full reference: auth, every endpoint, error codes, rate limits, versioning.

Machine-readable

• Swagger UI — try endpoints from the browser
• OpenAPI spec — import into Postman, or generate a client
• Health check — unauthenticated, for monitoring

Authentication in one paragraph

Every endpoint lives under /api — the docs you are reading sit at the root, so the path always says whether something is for a client or a browser. Every endpoint except /api/health requires an API key. Two headers travel on every model run — the key identifies your application, the second identifies the customer you are calling on behalf of:

Authorization: Bearer idxs_live_xxxxxxxx
X-End-User: nasabah_00471

X-End-User must be a stable, opaque id for that person — not an email. It is required on runs, and it is what makes per-user history work. Keep the API key server-side; it carries your full scopes and must never ship inside a mobile binary.

The two models FAIR uses

Both are asynchronous: POST /api/v1/models//runs?view=compact&wait=30 returns 200 with the result inline when it finishes in time, or 202 with a job id to poll. Implement both paths — a cold start will exceed the wait.