> For the complete documentation index, see [llms.txt](https://docs.idlayr.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.idlayr.com/products/eligibility/prerequisites.md).

# Prerequisites

{% hint style="info" %}
**Backend API** · GA
{% endhint %}

Eligibility is fundamentally a backend REST call. The IP endpoint additionally supports a device-assisted variant — see below.

## On the IDlayr side

* **An approved IDlayr project** with the `eligibility` scope on its OAuth2 credentials. See [Projects](/get-started/concepts/projects.md).
* **The project's `client_id` and `client_secret`.** See [Credentials](/get-started/concepts/credentials.md).
* **Allowed networks configured.** The Eligibility result reflects your project's [allowed networks](/get-started/concepts/allowed-networks.md) — carriers not on your allowed list are reported as unavailable regardless of technical reachability.

## On your backend

* A way to mint OAuth2 access tokens against `POST /oauth2/token`. See [Authentication](/get-started/authentication.md).
* A way to call `GET /v1/eligibility/phone-numbers/{phone_number}` or `GET /v1/eligibility/device-ips/{ip}` over HTTPS and read the synchronous response.
* For the **IP endpoint**: a way to obtain a meaningful IP for the query. Two paths:
  * **Server-observed IP** — the source IP of an inbound HTTP request from the device (or the right header behind a proxy: `X-Forwarded-For`, `True-Client-IP`, depending on your CDN). Caveats below.
  * **Device-captured IP via SDK** (recommended for mobile-web and native-app contexts) — the [IDlayr SDK](/get-started/sdks.md) on the device captures the real cellular IP and your app sends it back to your backend over your own application API. Your backend then calls the Eligibility endpoint with that IP. The OAuth2 access token stays on your backend.

## Server-observed IP — caveats

A server-observed IP is whatever the device's network path presented to your backend. It might be:

* The real cellular IP (best case — eligibility resolves cleanly to the MNO).
* A NAT'd IP from the user's home or corporate network (the device is on Wi-Fi, not cellular — Eligibility cannot resolve this to a mobile network).
* A proxy or VPN IP (the device's actual mobile path is hidden — Eligibility may resolve to the wrong network or to none).

The IP endpoint will faithfully tell you "not a mobile IP address" when the observed IP isn't from a mobile carrier. That's actionable: if you specifically need to know whether the device is currently on cellular, this answer is meaningful. If you instead need to know what the device *could* do over cellular — use the device-captured IP path below.

## Device-captured IP — what you need

For the SDK-captured IP path:

* The **iOS SDK** (`IDlayrKit`) or **Android SDK** (`idlayr-sdk-android`) installed in your app. See [iOS SDK](/get-started/sdks/ios.md) and [Android SDK](/get-started/sdks/android.md).
* An application API channel between the device and your backend so the device can send the captured IP up. The OAuth2 access token never goes to the device — your backend uses its own token to call IDlayr.
* The device must have **cellular data available** at the moment of capture (the SDK uses cellular pinning to ensure the observed IP is the real cellular IP).

The phone-number endpoint does not need any of this — it runs purely server-side.

## Network requirements

* **Your backend** needs egress to `{data_residency}.api.idlayr.com` over HTTPS.
* **The device** (if calling the IP endpoint via SDK) needs an active cellular data connection.

## Optional but recommended

* A **caching layer** for eligibility results if you'll re-check the same input multiple times in quick succession. Carriers change rarely; a short TTL (minutes) is reasonable for most use cases.
* A **decision tree** in your application logic for what to do with each possible outcome — all products available, partial, none. The point of Eligibility is to make that decision *before* incurring a verification call.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.idlayr.com/products/eligibility/prerequisites.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.