Request

To make request into IDSL API, it is the same way as make request to other RESTful API.

Base URL

IDSL provides a different base URL for prepaid and postpaid products, and a separate environment for development (sandbox) and production. Use the recommended URL below for new integrations — the legacy URLs remain supported for existing clients.

Prepaid (recommended)

Postpaid (recommended)

Environment Setup Checklist

Before making your first production request, complete these steps in order:

1. Register an IDSL account and activate it (production access requires activation).
2. Get API keys — you have separate keys for sandbox and production: get your API key.
3. Whitelist your IP — in production, requests are only accepted from whitelisted IPs. Add your server's public IP under Production Setting in the IDSL developer portal.
4. Top up your deposit — production transactions deduct from your IDSL wallet balance.
5. Set your callback URL (prepaid) — sandbox and production callbacks are configured separately.

Timezone & Timestamp

• When a response includes a transaction timestamp (datetime), it is formatted as YYYYMMDDHHMMSS (e.g. 20210316174828 = 2021-03-16 17:48:28 WIB, UTC+7). See the postpaid inquiry response example for a live sample.
• period fields (postpaid bills) are formatted as YYYYMM (e.g. 202103 = March 2021).
• All times are Indonesia Western Time (WIB, UTC+7). Deposit top-up is processed on business hours; see the FAQ for the current top-up schedule.

Schema

IDSL provide 2 request schema to make API request: JSON and XML. The request header must appropriate based on the request schema.

Content-Type: application/json

Content-Type: application/xml

Authentication

IDSL API use md5 hash to authenticate the requests. You need to put the sign key as request body and combination of md5 hash as value. The combination include username, api key, and additional.

sign: md5({username}+{api_key}+{additional})

additional : Based on the request commands. The additional will be explained in each api call later.

HTTP Status Codes

IDSL API returns a standard HTTP status code for every request. HTTP 200 means your request was received and processed — it does not mean the transaction succeeded. Always check the business response code (rc / response_code) and status inside the response body to know the actual result.

The API also names the exact reason inside the body, so read data.rc alongside the HTTP status: 204 wrong authentication, 100 invalid signature, 208 invalid data (credentials or payload rejected), 107 invalid format (a required field is missing or malformed — data.error_details names it), 210 invalid content type and 211 method not allowed are all setup problems you can fix in the request itself, not provider-side incidents.

Timeout & Retry

• Set your HTTP client timeout to at least 30 seconds — postpaid bill processing can take longer than typical REST calls.
• For prepaid, the first response is returned quickly (PROCESS), but the final result is asynchronous (approximately 1–30 seconds). Do not keep the connection open waiting for the result — use the callback or poll check status.
• Retry safely with the same ref_id: if you do not receive a response (timeout/network error), resend the same request with the same ref_id. IDSL treats a repeated ref_id as a status check — it will not create a duplicate transaction. Never generate a new ref_id when retrying, or you risk double-charging.
• On HTTP 4xx, fix the request first — retrying will not help. On HTTP 429, retry after a delay. On network errors / HTTP 5xx, wait a few seconds, then retry with the same ref_id.

Response Envelope

Every response is wrapped in a consistent envelope so your parser only needs to handle one shape:

• JSON: { "data": { ... }, "meta": [...] } — business fields live inside data.
• XML: <mp> ... </mp> — same fields as data, flat.

Example (postpaid inquiry):

{
  "data": {
    "tr_id": 99000008,
    "code": "PLNPOSTPAID",
    "hp": "530000000000",
    "ref_id": "09128374655",
    "response_code": "00",
    "message": "INQUIRY SUCCESS",
    "price": 302500,
    "selling_price": 301900
  },
  "meta": []
}

Note the two response-code fields across the docs: prepaid uses rc (e.g. rc: "00"), postpaid uses response_code. Both mean the same thing — check the value against the prepaid response code list or postpaid response code list.