A small API.
A clear response.

API reference for tools and agents

Use the OpenAPI specification for request schemas, or read the complete text reference. These documents describe the API; lookups still require authentication.

Get API access

Open the RapidAPI listing, choose an available plan, and find your application key. Customer requests go through the RapidAPI gateway, which manages authentication and usage.

Send X-RapidAPI-Key and X-RapidAPI-Host with your request. Use the values provided by your RapidAPI application. Keep the key in your backend or server environment.

curl -X POST \
  'https://game-id-checker-api.p.rapidapi.com/check' \
  -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  -H 'X-RapidAPI-Host: game-id-checker-api.p.rapidapi.com' \
  -H 'Content-Type: application/json' \
  -d '{"game":"mlbb","player_id":"123456789","zone_id":"1234"}'

Two endpoints. Every supported game.

Use GET /games?enabled=true for games currently enabled, with their IDs and required fields. Send the selected game ID to POST /check. New games use these same two endpoints.

Paths are relative to the RapidAPI gateway, or https://gameidchecker.com/api/v1 for direct owner access. Both endpoints require authentication.

Each API catalogue entry contains only id, name and required_fields. Use these to build your game selector and request form. See the linked game guides for ID formats and maximum lengths. Wild Rift uses a combined Name#Tag string and is currently unavailable. Filtering by enabled status describes configuration, not live provider health. Unsupported game IDs return 400; disabled games return 503 on lookup.

curl 'https://game-id-checker-api.p.rapidapi.com/games?enabled=true'   -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY'   -H 'X-RapidAPI-Host: game-id-checker-api.p.rapidapi.com'

Request fields

Send a JSON object with Content-Type: application/json. Numeric identifiers are strings to preserve their exact values.

The request body limit is 4 KiB. Fields other than game, player_id, and zone_id are rejected.

{
  "game": "mlbb",
  "player_id": "123456789",
  "zone_id": "1234"
}

{
  "game": "pubgm",
  "player_id": "5123456789"
}

Read the lookup result

A completed lookup returns HTTP 200 and success: true. Read data.valid to determine whether the provider found the account.

{
  "success": true,
  "data": {
    "game": "pubgm",
    "player_id": "5123456789",
    "valid": true,
    "nickname": "ExamplePlayer",
    "region_code": null
  },
  "checked_at": "2026-11-08T00:00:00.000Z",
  "request_id": "00000000-0000-4000-8000-000000000000"
}

data.region_code is always present on completed lookups: an uppercase two-letter account country code reported by the provider, such as MM, or null when unavailable. Availability varies by game and account. It is not inferred from zone_id or request location.

When the provider explicitly reports an invalid account, data.valid is false, and both data.nickname and data.region_code are null. Every response includes a request ID; completed checks also include a timestamp.

A nickname lookup does not prove account ownership. Ask the customer to review the returned account name before continuing a top-up workflow.

Handle errors deliberately

For transient errors, respect Retry-After when present. A provider failure must not be shown to a customer as “account does not exist.”

Use GET /games for the configured game catalogue and GET /health for Worker liveness. Liveness is not a guarantee of upstream availability.