The LookingGlass API query for a single IP address does not return data, but returns data after adding a mask

RIPEstat
1
  1. A single IP address returns an empty result.

curl --location --request GET “https://stat.ripe.net/data/looking-glass/data.json?resource=159.138.184.0” | jq | more
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 524 100 524 0 0 2846 0 --:–:-- --:–:-- --:–:-- 2863
{
“messages”: ,
“see_also”: ,
“version”: “2.1”,
“data_call_name”: “looking-glass”,
“data_call_status”: “supported”,
“cached”: false,
“query_id”: “20260824092119-98323d99-6180-4408-a98b-00f612c031bf”,
“process_time”: 107,
“server_id”: “app188”,
“build_version”: “v0.11.7-2026.08.19”,
“pipeline”: “1387518”,
“status”: “ok”,
“status_code”: 200,
“time”: “2026-08-24T09:21:19.194480”,
“data”: {
“rrcs”: ,
“query_time”: “2026-08-24T09:21:19”,
“latest_time”: “2026-08-24T09:21:04”,
“parameters”: {
“resource”: “159.138.184.0”,
“look_back_limit”: 86400,
“cache”: null
}
}
}

  1. Adding a mask returns normal data.
    curl --location --request GET “https://stat.ripe.net/data/looking-glass/data.json?resource=159.138.184.0/24” | jq | more
    % Total % Received % Xferd Average Speed Time Time Time Current
    Dload Upload Total Spent Left Speed
    100 147k 100 147k 0 0 549k 0 --:–:-- --:–:-- --:–:-- 550k
    {
    “messages”: ,
    “see_also”: ,
    “version”: “2.1”,
    “data_call_name”: “looking-glass”,
    “data_call_status”: “supported”,
    “cached”: false,
    “query_id”: “20260824092126-b8d4a053-b2a7-4c07-a8eb-80ba130da49c”,
    “process_time”: 100,
    “server_id”: “app172”,
    “build_version”: “v0.11.7-2026.08.19”,
    “pipeline”: “1387518”,
    “status”: “ok”,
    “status_code”: 200,
    “time”: “2026-08-24T09:21:26.785250”,
    “data”: {
    “rrcs”: [
    {
    “rrc”: “RRC01”,
    “location”: “London, United Kingdom”,
    “scope”: “LINX / LONAP”,
    “peers”: [
    {
    “asn_origin”: “136907”,
    “as_path”: “15692 2914 3491 24413 136907”,
    “community”: “2914:420 2914:1203 2914:2201 2914:3200 3491:500 3491:517 3491:9001 3491:9080 3491:9081 3491:9087 3491:62210 3491:62220 15692:2000 15692:2100”,
    “largeCommunity”: “”,
    “extendedCommunity”: “”,
    “last_updated”: “2026-08-24T08:34:54.100000”,
    “prefix”: “159.138.184.0/24”,
    “peer”: “5.57.80.113”,
    “origin”: “IGP”,
    “next_hop”: “5.57.80.113”,
    “latest_time”: “2026-08-24T09:21:23.850000”,
    “community_info”: {
    “regular”: {
    “2914:420”: {
    “description”: “Peer routes”,
    “original”: “2914:420”
    },
    “2914:1203”: {
    “original”: “2914:1203”,
    “description”: “London, England”
    },
    “2914:2201”: {
    “original”: “2914:2201”,
    “description”: “uk (United Kingdom)”
    },
    “2914:3200”: {
    “original”: “2914:3200”,
    “description”: “Europe”
    },
    “3491:500”: {
    “original”: “3491:500”,
    “description”: “Africa customer”
    },
    “3491:517”: {
    “original”: “3491:517”,
    “description”: “JNB01 Johannesburg customer”
    },
    “3491:9001”: {
    “description”: “Customer”,
    “original”: “3491:9001”
    },
2

Hi,

This is confusing and appears to have been a transient error. We have (and historically have) had a feature that converts IP addresses to their routed prefix (using longest prefix matching).

This looks like "messages":[["info","IP address (159.138.184.0) has been converted to its encompassing routed prefix (159.138.184.0/24)"]] in the JSON response. This is not present in your sample.

I will ask a colleague to check how we handle a failure of a call to check for the longest prefix matching.