IP Check Advance AI Agent / LLM
IP and Network IntelligenceEverything an AI coding assistant needs to write a working IP Check Advance integration without opening another page: endpoint, authentication, parameters, a real request, both response shapes and the platform rules it cannot infer from a single example. Copy the brief below and paste it into Claude, Cursor, GitHub Copilot, ChatGPT or any other agent.
Machine-readable spec — Markdown
# IP Check Advance API — Way2API®
- **Endpoint:** `POST https://app.way2api.com/api/v1/ip/check_advance`
- **Auth:** `Authorization: Bearer YOUR_API_KEY` (or `X-API-Key: YOUR_API_KEY`)
- **Content-Type:** `application/json`
- **Category:** IP and Network Intelligence
- **Availability:** Available worldwide
- **Docs:** https://app.way2api.com/documentation/ip-check-advance
## What it does
IP Check Advance API — Deep IP intelligence for any IPv4 or IPv6 address. Beyond basic geolocation (city, country, coordinates, time zone), it returns rich network and risk signals: ISP, organization, ASN, connection type, user type, a static IP score, and anonymizer flags — is_anonymous, is_anonymous_vpn, is_public_proxy, is_residential_proxy and is_tor_exit_node. Built for fraud scoring, login-risk checks, and geo-targeting. ip_address is optional — omit it to auto-detect and look up the IP that called this API. Fields the source cannot resolve for a given address are omitted from the result.
## Request body (application/json)
| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `ip_address` | string | no | IPv4 or IPv6 address to look up (e.g. 122.180.145.105 or 2001:db8::1). Optional — if omitted, the IP that called this API is auto-detected and used. |
## Example request
```bash
curl -X POST https://app.way2api.com/api/v1/ip/check_advance \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"ip_address":"122.180.149.100"}'
```
## Success response — 200
```json
{
"status": "SUCCESS",
"status_code": 200,
"charged": true,
"success": true,
"message": "",
"message_code": "OK",
"order_id": "W2A1739512345abcdef01",
"data": {
"order_id": "W2A1739512345abcdef01",
"result": {
"city": {
"confidence": 30,
"geoname_id": 1261481,
"names": {
"en": "New Delhi"
}
},
"continent": {
"code": "AS",
"geoname_id": 6255147,
"names": {
"en": "Asia"
}
},
"country": {
"confidence": 99,
"iso_code": "IN",
"geoname_id": 1269750,
"names": {
"en": "India"
}
},
"location": {
"accuracy_radius": 20,
"latitude": 28.6327,
"longitude": 77.2198,
"time_zone": "Asia/Kolkata"
},
"postal": {
"confidence": 1,
"code": "110002"
},
"registered_country": {
"iso_code": "IN",
"geoname_id": 1269750,
"names": {
"en": "India"
}
},
"subdivisions": [
{
"confidence": 30,
"iso_code": "DL",
"geoname_id": 1273293,
"names": {
"en": "National Capital Territory of Delhi"
}
}
],
"traits": {
"static_ip_score": 5,
"user_count": 2,
"user_type": "residential",
"autonomous_system_number": 24560,
"autonomous_system_organization": "Bharti Airtel Ltd., Telemedia Services",
"connection_type": "Cable/DSL",
"domain": "airtel.in",
"isp": "Airtel",
"organization": "Airtel",
"ip_address": "122.180.149.100",
"network": "122.180.149.100/32"
}
}
}
}
```
## Error response — 400
```json
{
"status": "FAILED",
"status_code": 400,
"charged": false,
"success": false,
"message": "The address 203.0.113.1 is not in our database.",
"message_code": "REQUEST_FAILED",
"order_id": "W2A1739512345abcdef01",
"data": {
"order_id": "W2A1739512345abcdef01",
"error_code": "IP_ADDRESS_NOT_FOUND"
}
}
```
## Integration rules
- Every response is JSON carrying `status`, `status_code`, `charged`, `success`, `message`, `message_code` and (once a call reaches the provider) `order_id`. The verification payload is under `data.result`.
- `charged` (boolean) is the authority on billing. Do NOT infer it from the HTTP status: `422` is returned both for input we rejected (not charged) and for a lookup the provider ran and billed us for that returned a negative result (charged).
- `message_code` is a fixed vocabulary — branch on it instead of parsing `message`. Values: `OK`, `ACCEPTED`, `PROVIDER_NO_RESPONSE`, `VERIFICATION_FAILED`, `NO_RECORD_FOUND`, `INVALID_INPUT`, `REQUEST_FAILED`, `MISSING_API_KEY`, `INVALID_API_KEY`, `INSUFFICIENT_BALANCE`, `NO_API_ACCESS`, `NOT_FOUND`, `RATE_LIMITED`, `INTERNAL_ERROR`, `PROVIDER_UNAVAILABLE`.
- `success` reports the verification outcome; `status` reports the ORDER lifecycle (`SUCCESS`/`PENDING`/`FAILED`). They differ on a charged negative result: the order completed and was billed while the verification did not pass.
- A failed verification is still a successful HTTP call — the outcome lives in the response body, so do not treat `200` as "verified".
- Status codes: `200` result returned, `202` pending or provider did not respond (both charged — quote the `order_id`), `401` missing/invalid key, `402` insufficient balance, `403` no access to this service, `422` see `charged`, `429` rate limited (honour the `Retry-After` header), `503` temporarily unavailable.
- Rate limits are per API key, per service, on a 1-minute sliding window.
- Load the API key from an environment variable or secret store. Never hard-code it, never commit it, and never ship it in client-side code — calls must be made from your backend.
Prompts to pair it with
- Write a production-ready IP Check Advance integration in PHP using this spec, with error handling and retries.
- Given this spec, generate typed request/response models and a client class.
- Review my existing IP Check Advance integration against this spec and list what I handle incorrectly.
⚠ Before you paste generated code
Never let an assistant hard-code your API key — load it from an environment variable or a
secret store, and call this endpoint from your backend only. A failed verification is still a
successful HTTP call, so check the success field in the body
rather than treating 200 as verified.